I'm a Lispworks user.
We have Enterprise version 4.4.6 with 1 year contract.
So we are eligible for upgrade prices for new version of Lispworks 5.0
Today, i saw a promotional from Allegro:
http://www.franz.com/products/packages/?from=rss
They offer to Lispwroks users to upgrade to ALC for same price as
upgrade to Lispwroks 5.0
So here goes my question.
Can anyone compare these 2 products and list the differences.
I'm specificly intrested in windows 32 versions.
And multhi-threading support.
I saw 1 message here saying that Lispworks does not have true OS
multithreading.
Is this correct ?
Vagif Verdi wrote:
> I'm a Lispworks user.
> We have Enterprise version 4.4.6 with 1 year contract.
> So we are eligible for upgrade prices for new version of Lispworks 5.0
>
> Today, i saw a promotional from Allegro:
> http://www.franz.com/products/packages/?from=rss
> They offer to Lispwroks users to upgrade to ALC for same price as
> upgrade to Lispwroks 5.0
>
> So here goes my question.
> Can anyone compare these 2 products and list the differences.
> I'm specificly intrested in windows 32 versions.
> And multhi-threading support.
> I saw 1 message here saying that Lispworks does not have true OS
> multithreading.
> Is this correct ?
I find LispWorks's IDE to be much more comfortable than Allegro's.
This could be because I've always been an Emacs user (LispWorks's
editor has the Emacs-nature), but I just find the whole environment to
be much more cleanly laid out than Allegro. The LispWorks environment
can be customized (and complete source for the editor comes with a
Professional license), so you aren't so limited in what the IDE can do.
I don't know how Franz compares in this area. I also really like the
LispWorks Interface Builder (putting controls in layouts beats dragging
and dropping them into place) and the CAPI toolkit is extra nice.
Franz's Common Graphics and its associated designer felt uncomfortably
like I was programming VB. But then again, I didn't play with the GUI
parts of Allegro for more than a few hours. On the other hand, Allegro
seems like it comes with more libraries out of the box. There is also
AllegroCache, if you buy the Enterprise edition (or the Professional
AllegroCache has restrictions like a maximum of 1,000,000 commits, etc.
but that could be enough); I don't know of anything comparable to
AllegroCache available for non-Allegro systems (rucksack?). I don't
know anything about Franz support but I generally hear good things.
LispWorks has "true OS multithreading" -- the problem that someone
mentioned here was that it can't take advantage of multi-CPU systems.
They are still real native threads.
The article is slightly misleading, I think. LispWorks doesn't give
you 5 "support questions." You have an unlimited number of questions,
but you only have 5 "chargeable incidents." These are defined on their
website, but as I understand it they generally involve LispWorks making
changes to its software or doing other extraordinary things. The
advantage of this scheme is that you can buy more chargeable incidents
if you need them, instead of committing to royalties up front in case
you need support. I just find the concept of paying royalties so
odious that even if I liked Allegro better than LispWorks (I don't),
I'd end up going elsewhere.
HTH,
Bill
> LispWorks has "true OS multithreading" -- the problem that someone
> mentioned here was that it can't take advantage of multi-CPU systems.
> They are still real native threads.
I must say that today i wouldn't call anything that forbids this as
"true OS multithreading".
llothar wrote:
> > LispWorks has "true OS multithreading" -- the problem that someone
> > mentioned here was that it can't take advantage of multi-CPU systems.
> > They are still real native threads.
>
> I must say that today i wouldn't call anything that forbids this as
> "true OS multithreading".
I have to ask: aren't you looking at Lisp for coding an IDE? Do you
think an IDE will tax a system so heavily that being able to run on
multiple CPU's will make or break your application? This is an honest
question.
Bill Atkins wrote:
> llothar wrote:
> > > LispWorks has "true OS multithreading" -- the problem that someone
> > > mentioned here was that it can't take advantage of multi-CPU systems.
> > > They are still real native threads.
> >
> > I must say that today i wouldn't call anything that forbids this as
> > "true OS multithreading".
>
> I have to ask: aren't you looking at Lisp for coding an IDE?
Coding an IDE !?
In most cases you create end user applications or server side
applications, not programmer tools.
For example I'm using lisp as web server and as rule engine that
resides on web server.
This is a server and multi-cpu environment, so such a limitation is
very bad for me.
So for me (and all other who do web development) true multi-threading
is a an important issue.
But then again, you nailed it - royalties are a showstopper for us too.
Vagif Verdi wrote:
> Bill Atkins wrote:
> > llothar wrote:
> > > > LispWorks has "true OS multithreading" -- the problem that someone
> > > > mentioned here was that it can't take advantage of multi-CPU systems.
> > > > They are still real native threads.
> > >
> > > I must say that today i wouldn't call anything that forbids this as
> > > "true OS multithreading".
> >
> > I have to ask: aren't you looking at Lisp for coding an IDE?
>
> Coding an IDE !?
> In most cases you create end user applications or server side
> applications, not programmer tools.
Hmm, I was talking to Lothar. Lothar is the author of a suite of IDE's
and he's been asking about rewriting these in Lisp.
> For example I'm using lisp as web server and as rule engine that
> resides on web server.
> This is a server and multi-cpu environment, so such a limitation is
> very bad for me.
>
> So for me (and all other who do web development) true multi-threading
> is a an important issue.
You can always start two OS processes running the same Lisp code. I'm
not sure what else to tell you.
> But then again, you nailed it - royalties are a showstopper for us too.
From: Espen Vestre
Subject: Re: Comparison of Lispworks and Allegro CL
Date:
Message-ID: <m1slk7btgc.fsf@vestre.net>
"Bill Atkins" <·········@gmail.com> writes:
> You can always start two OS processes running the same Lisp code. I'm
> not sure what else to tell you.
Most of our server software is made with LW. Most of our newer servers
for lisp deployment are dual-dual Opteron servers with at least 4GB
RAM (side note: Opteron is much, much faster for delivered LW apps
than P4 based Xeon, but we're looking into Intel Core 2 now, i.e.
Xeon 5100 - seems to beat Opteron). And we do exactly what you
suggest: Run several OS processes on each server. Most of our stuff
need to be scaleable beyond what you can run on a single machine
anyway (well, maybe except if you're a fan of multi-multi-cpu
fridge-size Sun systems ;-)), so running several instances on one
machine really isn't a problem.
--
(espen)
> Most of our server software is made with LW. Most of our newer servers
> for lisp deployment are dual-dual Opteron servers with at least 4GB
> RAM (side note: Opteron is much, much faster for delivered LW apps
> than P4 based Xeon, but we're looking into Intel Core 2 now, i.e.
> Xeon 5100 - seems to beat Opteron). And we do exactly what you
> suggest: Run several OS processes on each server. Most of our stuff
> need to be scaleable beyond what you can run on a single machine
> anyway (well, maybe except if you're a fan of multi-multi-cpu
> fridge-size Sun systems ;-)), so running several instances on one
> machine really isn't a problem.
I think this depends a lot of what you want to do. There are many types
where
synchronization is not so easy and data transfer via a database (which
is the common solutions) is killing the benefits. And if i would use
Lisp instead of PHP or Rails then it should be a little bit more
complex otherwise it will not justify the use this language.
> I have to ask: aren't you looking at Lisp for coding an IDE? Do you
> think an IDE will tax a system so heavily that being able to run on
> multiple CPU's will make or break your application? This is an honest
> question.
No. I think the chance are good that there is not such a high penality,
but even here
you can do a lot of background parsing and KI algorithms when you want
to try to provide
interactive intelligent code analysis while you type. I have a lot of
ideas i want to try out when i enter this area.
But much more important is that maybe this is not the _ONLY_ project
that i want to do when i already payed a lot of money. And it is easy
to see that it is a problem for many problem domains.
On 7 Aug 2006 15:10:18 -0700, "Bill Atkins" <·········@gmail.com>
wrote:
>
>LispWorks has "true OS multithreading" -- the problem that someone
>mentioned here was that it can't take advantage of multi-CPU systems.
>They are still real native threads.
>
Most shared memory, multi-CPU OSes have symmetric multitasking which,
by default, schedule threads across all CPUs unless the application
(or the shell that launched it) does something to deliberately
restrict process/thread affinity.
Is there some technical reason (GC maybe?) for restricting CPU
affinity in an otherwise multithreaded Lisp? Or is it an artificial
restriction because they haven't been vetted on multiple CPUs and so
the results can't guaranteed?
In either case, multi-core machines are here to stay so Lisp vendors
had better make peace with that.
George
--
for email reply remove "/" from address
> Is there some technical reason (GC maybe?) for restricting CPU
> affinity in an otherwise multithreaded Lisp? Or is it an artificial
> restriction because they haven't been vetted on multiple CPUs and so
> the results can't guaranteed?
The whole implementation is a problem, maybe core parts like the GC are
one of the easiest part. The largest problem is that lisp was never
designed with this idea in mind and so it is almost impossible to
provide this feature without changing the semantic. If you don't do
this, your system will be extremely easy to crash on each minor error.
There are reasons why for example strings and others heavy used objects
have to be immutable to avoid either excessive locking or make it a
serious problem.
Look at the many internal data structures that lisp is using, Even
simple list operations can crash the system.
Thats why there doesn't exist any multithreaded scripting language.
Perl is forking, TCL is using shared nothing, Python,Ruby are doing it
like LW, PHP does not do anything. Smalltalk - even the more expensive
visual works - has the same problems, no multithreading, thats it.
IMHO if you want to support multithreading you have to design a
langauge from scratch to do it. Otherwise it will not work (well).
> In either case, multi-core machines are here to stay so Lisp vendors
> had better make peace with that.
I can't agree more. Time to do another language fork.
llothar wrote:
> The whole implementation is a problem, maybe core parts like the GC are
> one of the easiest part. The largest problem is that lisp was never
> designed with this idea in mind and so it is almost impossible to
> provide this feature without changing the semantic. If you don't do
> this, your system will be extremely easy to crash on each minor error.
I think that it should be pretty viable to extend CL CL work on
shared-memory multi-CPU (multi-core really) machines, as far as the
language goes. You obviously need a (carefully-designed, not some
based-on-what-the-lispm-did botch) set of locking / atomic primitives,
but these can be added to the language without interfering with the
rest of it. You then probably need to specify atomicity of existing
functions, but I suspect that for most of them the answer can just be
`they're not' (perhaps hashing ops should be).
Typically I think most of the hard work would be in the implementation,
because I bet existing implementations are pretty cavalier about
things, and if you want to be able to synchronize on any object that
might have a very large impact on implementations, etc. And programs
then need to be changed to not be cavalier as well.
I'm basing this on having thought about it a fair bit, but some time
ago, and having looked at how Java does things, which seems to have
been initially to specify that lots of things were atomic and then
backtrack on this because it made performance suck, but to have a
reasonably competently designed set of locking & synchronization
primitives (which would be much easier to retrofit to CL than to a
C-family language). And Java implementations do run on genuinely large
machines (there are people who sell special java boxes with, I think,
hundreds of cores, although I suspect they will not be (have not been?)
commercially successful at that).
--tim
From: Russell McManus
Subject: Re: Comparison of Lispworks and Allegro CL
Date:
Message-ID: <8764h1v9sb.fsf@cl-user.org>
"Tim Bradshaw" <··········@tfeb.org> writes:
> I think that it should be pretty viable to extend CL CL work on
> shared-memory multi-CPU (multi-core really) machines, as far as the
> language goes. You obviously need a (carefully-designed, not some
> based-on-what-the-lispm-did botch) set of locking / atomic primitives,
> but these can be added to the language without interfering with the
> rest of it. You then probably need to specify atomicity of existing
> functions, but I suspect that for most of them the answer can just be
> `they're not' (perhaps hashing ops should be).
>
> Typically I think most of the hard work would be in the implementation,
> because I bet existing implementations are pretty cavalier about
> things, and if you want to be able to synchronize on any object that
> might have a very large impact on implementations, etc. And programs
> then need to be changed to not be cavalier as well.
This sounds like an advertisement for erlang-style message passing.
-russ
Russell McManus wrote:
> This sounds like an advertisement for erlang-style message passing.
I don't think so, or at least it wasn't meant to be. Modern multicore
machines are (almost?) all shared-memory systems and a huge amount of
effort has gone into solving cache-coherency issues to make them
usable, and bandwidth-to-memory issues to make them scale.
Applications that want to make use of this hardware are probably best
written to expose the existence of shared address space as far as
possible, not hide it behind message passing, which would sit more
naturally on shared-nothing systems.
--tim
From: Russell McManus
Subject: Re: Comparison of Lispworks and Allegro CL
Date:
Message-ID: <871wrnv6t1.fsf@cl-user.org>
"Tim Bradshaw" <··········@tfeb.org> writes:
> Russell McManus wrote:
>
>> This sounds like an advertisement for erlang-style message passing.
>
> I don't think so, or at least it wasn't meant to be. Modern multicore
> machines are (almost?) all shared-memory systems and a huge amount of
> effort has gone into solving cache-coherency issues to make them
> usable, and bandwidth-to-memory issues to make them scale.
I'm aware of the effort that has been invested to make these beasts
work. But if the software writers adopt message passing, then we can
have simplicity at the systems level, and get truly distributed
computation. This seems like a huge win to me.
The system should make this convenient. Perhaps there should be a
metaclass that only allows you to create immutable objects, and then
things like Lispwork's mailboxes into which you can only put such
objects. These objects could have a universal serialization protocol
defined, and then the mailboxes could be local or remote.
> Applications that want to make use of this hardware are probably
> best written to expose the existence of shared address space as far
> as possible, not hide it behind message passing, which would sit
> more naturally on shared-nothing systems.
Of course applications that want to make use of a system should play
to it's strengths.
But I'm thinking one step back from this, about whether such systems
are worth the mountain of complexity they require. Almost always the
most limited resource is programmer cycles, not cpu cycles, and the
deadlocks, race conditions, priority inversions, etc. etc. of shared
memory multithreading for the most part goes away when you adopt
message passing instead.
When I'm programming in Lisp, I don't want to worry about such things,
but prefer to stay in the problem domain.
-russ
Russell McManus wrote:
> I'm aware of the effort that has been invested to make these beasts
> work. But if the software writers adopt message passing, then we can
> have simplicity at the systems level, and get truly distributed
> computation. This seems like a huge win to me.
There is a project called DragonFlyBSD that is working on this. They
adopted Amiga-style message passing and lightweight kernel threads that
can be moved from one CPU to another. The current stage is the
cache-coherency system.
Eventually, a couple of boxes connected together will be able to move
an entire process from one CPU to another, while sharing the memory.
It's pretty complicated, but very interesting. I keep an eye on what's
going on, but as Russ said, I'll stick with the problem domain.
Russell McManus wrote:
> I'm aware of the effort that has been invested to make these beasts
> work. But if the software writers adopt message passing, then we can
> have simplicity at the systems level, and get truly distributed
> computation. This seems like a huge win to me.
There is a project called DragonFlyBSD that is working on this. They
adopted Amiga-style message passing and lightweight kernel threads that
can be moved from one CPU to another. The current stage is the
cache-coherency system.
Eventually, a couple of boxes connected together will be able to move
an entire process from one CPU to another, while sharing the memory.
It's pretty complicated, but very interesting. I keep an eye on what's
going on, but as Russ said, I'll stick with the problem domain.
Russell McManus wrote:
> "Tim Bradshaw" <··········@tfeb.org> writes:
>
>
>>Russell McManus wrote:
>>
>>
>>>This sounds like an advertisement for erlang-style message passing.
>>
...<snip>...
>
> The system should make this convenient. Perhaps there should be a
> metaclass that only allows you to create immutable objects, and then
> things like Lispwork's mailboxes into which you can only put such
> objects. These objects could have a universal serialization protocol
> defined, and then the mailboxes could be local or remote.
>
This sounds to me like an advertisement for... oh, never mind.
:)
kenneth
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Russell McManus wrote:
> But I'm thinking one step back from this, about whether such systems
> are worth the mountain of complexity they require. Almost always the
> most limited resource is programmer cycles, not cpu cycles, and the
> deadlocks, race conditions, priority inversions, etc. etc. of shared
> memory multithreading for the most part goes away when you adopt
> message passing instead.
>
Well, firstly, if you're not short of CPU cycles you don't need a big
parallel box (or even a small parallel box).
A long time ago when I was interested in supercomputers, physics &
such[*], I went to a seminar on the future of supercomputers. At that
time the big machines were pretty much all shared-nothing, or
non-cache-coherent shared memory, because they obviously scaled better.
The guy pointed out that there was not enough money left in the world
to support the kind of design and fabrication effort for machines
designed purely for science (or, really, for simulating bombs etc). So
the only machines that would survive, outside some very weird niches,
would be machines driven by commercial applications. And those
commercial applications are databases, and they all want shared memory
because it's so much simpler (yes) and more effivient than message
passing. So that is what machines would all look like in 5-10 years.
And lo, he was right: that *is* what they all look like. Both big
systems and small systems.
(I think there's a common misunderstanding that somehow shared-nothing
machines are much easier top build than shared-memory ones - you just
need to string up some interconnect right? People who think this
generally haven't looked at where the money goes in such systems (hint:
the interconnect)).
[*] OK, I still am.
From: Russell McManus
Subject: Re: Comparison of Lispworks and Allegro CL
Date:
Message-ID: <87d5awu20c.fsf@cl-user.org>
"Tim Bradshaw" <··········@tfeb.org> writes:
> A long time ago when I was interested in supercomputers, physics &
> such[*], I went to a seminar on the future of supercomputers. At that
> time the big machines were pretty much all shared-nothing, or
> non-cache-coherent shared memory, because they obviously scaled better.
> The guy pointed out that there was not enough money left in the world
> to support the kind of design and fabrication effort for machines
> designed purely for science (or, really, for simulating bombs etc). So
> the only machines that would survive, outside some very weird niches,
> would be machines driven by commercial applications. And those
> commercial applications are databases
You are making quite a statement there which I don't think is
supportable. I work in the financial markets on applications that
process lots of event-driven data, and there are no databases in
sight. For this type of work we use clusters of cheap computers that
communicate using message passing.
I think that you're right that shared state machines make large
databases easier. But somehow Google seems to have figured out how to
distribute a large percentage of the worlds recorded knowledge across
a bunch of cheap machines, with minimal shared state.
-russ
Russell McManus wrote:
>
>
> I think that you're right that shared state machines make large
> databases easier. But somehow Google seems to have figured out how to
> distribute a large percentage of the worlds recorded knowledge across
> a bunch of cheap machines, with minimal shared state.
Google, of course, have been very smart. They've found what's called
an `embarrassingly parallel' problem - web search - and managed to make
a lot of money out of solving it. Embarrassingly parallel problems are
ones with a high degree of parallelism, and typically few or no
communication requirements: web search is such because you can easily
distrubute the data and there are basically no coherency requirements
(who cares, or even knows, if the set of results you get miss a few, or
vay slightly in order?). Consider how different this is, say, to the
kind of thing you'd need to run an investment bank's trading system or
a telco billing system: it's *really* important that those systems
don't lose coherency.
There are a relatively small number of high-profile scenarios where
loose-coherency systems do very well. Some of them are commercially
important (google, various financial exploratory systems &c), some
others are important to the military (simulating bombs or the weather),
and some are otherwise high profile (SETI).
But there are millions and millions of cases where ACID systems matter,
and they thrive on cache-coherent SMP machines. Which is why (almost?)
all commercial multiprocessors are such.
--tim
llothar wrote:
>>Is there some technical reason (GC maybe?) for restricting CPU
>>affinity in an otherwise multithreaded Lisp? Or is it an artificial
>>restriction because they haven't been vetted on multiple CPUs and so
>>the results can't guaranteed?
>
>
> The whole implementation is a problem, maybe core parts like the GC are
> one of the easiest part. The largest problem is that lisp was never
> designed with this idea in mind and so it is almost impossible to
> provide this feature without changing the semantic. If you don't do
> this, your system will be extremely easy to crash on each minor error.
As there are enough lisps around which provide multi-cpu multithreading,
which lisp semantics need to be changed?
>
> There are reasons why for example strings and others heavy used objects
> have to be immutable to avoid either excessive locking or make it a
> serious problem.
In general, you have to lock mutable structures accessed by multiple
threads. But there are no problems with structures which are not changed
by more than one thread and there are no problems at all with
thread-local variables.
> Look at the many internal data structures that lisp is using, Even
> simple list operations can crash the system.
Can you describe a way a simple list operation can "crash the system"?
> Thats why there doesn't exist any multithreaded scripting language.
> Perl is forking, TCL is using shared nothing, Python,Ruby are doing it
> like LW, PHP does not do anything. Smalltalk - even the more expensive
> visual works - has the same problems, no multithreading, thats it.
>
> IMHO if you want to support multithreading you have to design a
> langauge from scratch to do it. Otherwise it will not work (well).
What do you need what is not in Lisp/cannot be added to the language?
>
>
>>In either case, multi-core machines are here to stay so Lisp vendors
>>had better make peace with that.
>
>
> I can't agree more. Time to do another language fork.
Again, for which feature that cannot be added to Lisp do you need
to fork the language?
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
On Tue, 08 Aug 2006 01:11:19 -0400, George Neuner wrote:
> Most shared memory, multi-CPU OSes have symmetric multitasking which,
> by default, schedule threads across all CPUs
...
> multi-core machines are here to stay so Lisp vendors
> had better make peace with that.
How did connection machine lisp handle similar issues (or are the
differences too much to make illuminating comparisons)?
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
On Tue, 08 Aug 2006 17:34:20 -0500, Matthew D Swank
<·······································@c.net> wrote:
>On Tue, 08 Aug 2006 01:11:19 -0400, George Neuner wrote:
>> Most shared memory, multi-CPU OSes have symmetric multitasking which,
>> by default, schedule threads across all CPUs
>...
>
>> multi-core machines are here to stay so Lisp vendors
>> had better make peace with that.
>
>How did connection machine lisp handle similar issues (or are the
>differences too much to make illuminating comparisons)?
>
The Connection Machines were separate memory, message passing
architectures. The CM-1 and the various members of the 2 series were
bit-serial SIMD designs with the 2's adding a shared FPU to each
incremental block of ALUs. The CM-5 series were MIMD designs where
each CPU element was a 32-bit SPARC with 4 attached vector processors.
Most of my work was done in PARIS and C*, I only screwed around a bit
with *Lisp on a CM-2 and never had the chance to work with a CM-5 or
with the later CM-Lisp.
From what I remember of *Lisp, it's support for parallelism was very
simple and I don't think it has anything relevent to contribute to a
discussion of programming MIMD shared memory systems. But I would be
interested in hearing about anyone's experiences with CM-Lisp or with
Lisp on the CM-5. I sort of doubt there's anything relevent there
either but I would be delighted to hear otherwise.
George
--
for email reply remove "/" from address
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Comparison of Lispworks and Allegro CL
Date:
Message-ID: <87d5b4wmm0.fsf@qrnik.zagroda>
"Bill Atkins" <·········@gmail.com> writes:
> LispWorks has "true OS multithreading" -- the problem that someone
> mentioned here was that it can't take advantage of multi-CPU systems.
> They are still real native threads.
Using native threads which don't run in parallel combines the worst
aspects of two choices: threads are as heavy as in native threading,
but they don't use parallelism for efficiency as in green threading.
(I don't know how LW works, I'm basing on the above descrption.)
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> "Bill Atkins" <·········@gmail.com> writes:
>
> > LispWorks has "true OS multithreading" -- the problem that someone
> > mentioned here was that it can't take advantage of multi-CPU systems.
> > They are still real native threads.
>
> Using native threads which don't run in parallel combines the worst
> aspects of two choices: threads are as heavy as in native threading,
> but they don't use parallelism for efficiency as in green threading.
So why did the developers LispWorks use native threads? What do
you think?
AFAIK it has advantages for calling foreign code. For example other
threads would
still be able to run, when you call and wait in some thread. It
seems that this was more important for their customers, than support
of multiple cpus.
Let me guess, if there is sufficient customer demand (= money),
LispWorks
will have multi-cpu threads in some future version.
>
> (I don't know how LW works, I'm basing on the above descrption.)
>
> --
> __("< Marcin Kowalczyk
> \__/ ······@knm.org.pl
> ^^ http://qrnik.knm.org.pl/~qrczak/
Vagif Verdi wrote:
> I'm a Lispworks user.
> We have Enterprise version 4.4.6 with 1 year contract.
> So we are eligible for upgrade prices for new version of Lispworks 5.0
>
> Today, i saw a promotional from Allegro:
> http://www.franz.com/products/packages/?from=rss
> They offer to Lispwroks users to upgrade to ALC for same price as
> upgrade to Lispwroks 5.0
>
> So here goes my question.
> Can anyone compare these 2 products and list the differences.
I vastly prefer the ACL IDE (and I do get to play with the LW IDE when
porting o/s stuff to LW Trial).
But have you considered the cost of licensing for deployment, even
internally? This is something you need to get clear /before/ committing
to ACL.
> I'm specificly intrested in windows 32 versions.
That is what I use.
> And multhi-threading support.
Don't know anything about that.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
>But have you considered the cost of licensing for deployment, even internally?
What do you mean ? From their promotion ad, it is clear that they offer
exactly same terms as Lisworks, ie flat price, no licensing fees.
Or am I wrong ? If royalties are included, then forget it of course.
Vagif Verdi wrote:
> Ken Tilton wrote:
>
>>But have you considered the cost of licensing for deployment, even internally?
>
>
> What do you mean ? From their promotion ad, it is clear that they offer
> exactly same terms as Lisworks, ie flat price, no licensing fees.
> Or am I wrong ?
You better talk to them. I think you are reading things between the
lines that are not there. You read "hey, pay exactly the same" and
assumed "get exactly the same". I just read it again and do not see
anything on licensing, nor do I see anywhere anything about "exactly
the same terms". But maybe I am the one missing something. talk to them
and be explicit about what you want/need.
btw, i do not know aything about LW so this is not meant as a contrast,
but Franz tech support is awesome.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
The LispWorks' price can be found on the web, but I cannot find the
price of Allegro Common Lisp. And, the maintanence fee / upgrade fee
for LispWorks seem high. However I am not sure how expensive Allegro is.
············@gmail.com wrote:
> The LispWorks' price can be found on the web, but I cannot find the
> price of Allegro Common Lisp. And, the maintanence fee / upgrade fee
> for LispWorks seem high. However I am not sure how expensive Allegro is.
I might be wrong on this, but I seem to recall asking a couple of
months ago. I think the answer ranged between $1500 and $6000. It was
a phone conversation, so I have to email backup.
From: Ken Tilton
Subject: Re: Comparison of Lispworks and Allegro CL
Date:
Message-ID: <ymZBg.1024$Fs3.489@fe09.lga>
············@gmail.com wrote:
> The LispWorks' price can be found on the web, but I cannot find the
> price of Allegro Common Lisp.
You have to write/talk to Franz sales and haggle. Good luck with that.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Vagif Verdi wrote:
> I'm a Lispworks user.
> We have Enterprise version 4.4.6 with 1 year contract.
> So we are eligible for upgrade prices for new version of Lispworks 5.0
I am without a doubt a huge fan of Lispworks; both the product and the
company. We're currently running 4.4 Enterprise and will be moving to
5.0; our app is a state-of-the-art expert system that has soft
real-time requirements and integrates with Java clients and database
systems. I can't give any more details, but I can say I spent several
years prior to this work using ACL. Franz's offering is a very fine
product; I simply prefer Lispworks' development philosophy and its
method of doing business.
-- david
Hello Vagif,
I have bought LispWorks licenses for Windows, Mac, and Linux - my own
money for work on my own business ideas.
I also am using Franz Lisp on a long term job for a customer in the
heath care industry.
The short answer is that both LispWorks and Franz are very fine
products, but meet very different needs:
LispWorks: free runtime deployment. This is huge if you want to write a
web service for that will run on many servers or want to sell a
commercial product. I used to sell a NLP commercial product built with
LispWorks and was very pleased with its stand alone application
building functionality. They provide good tech support, when I have
needed it.
Franz: provides even better support (which must be a really high
business cost to them because world-class people like John Foderaro
provide tech support!) than LispWorks. While a development system is
not much more expensive that LispWorks, deployment licenses are
expensive. Franz provides out of the box better libraries for web
services, etc. Franz provides a very secure feeling when doing
important high value projects, but be sure to check deployment costs,
which are expensive.
I find both products a pleasure to use.
-Mark