Hi,
We're looking at adding a new Sun server that would primarily be used
for developing and running Lisp apps. One of the choices is between a
Sun Fire 280 R with two 750MHz UltraSPARC-III processors/ 2GB memory and
a Sun Blade 1000 Workstation Model 1750 with one 750 MHz UltraSPARC III
Processor /4GB Memory. I'm not sure how evaluate the trade-offs between
more processors vs. more memory, especially in terms of how it would
affect Lisp application performance. Can anyone shed some light on
this? Also, some general recommendations on which of the newer servers
would be good for Lisp work would be welcome.
Thanks,
Ben
Ben Olasov <···@rctbank.ucsf.edu> writes:
> I'm not sure how evaluate the trade-offs between more processors
> vs. more memory, especially in terms of how it would affect Lisp
> application performance.
It depends on your Lisp application, but typically Lisp apps really
like memory. You should consider adding memory no matter what you
buy. Memory's cheap.
> Also, some general recommendations on which of the newer servers
> would be good for Lisp work would be welcome.
Assuming you have about $10-$15k to spend, if your apps will fit into
1 GB of RAM and you want the most sparc bang for your buck, you should
consider buying a dozen Sun Netra X1s (US$995 each list), load them up
with memory (probably $180 each to upgrade them to 1GB), and stick
them into a grid.
http://www.sun.com/software/grid/
If your apps are larger or you must buy the more expensive 280R or Sun
Blade 1000 for some reason, then you should consider waiting for the
1.05 GHz units scheduled for early next year.
http://www.sun.com/smi/Press/sunflash/2001-11/sunflash.20011119.2.html
or at least get the 900 MHz units available now. Personally I
wouldn't bother with the Sun Blade 1000 unless you need a workstation.
Just curious, though: why not use x86 hardware? If your app is
CPU-bound and fits in 32 bits, x86 is most likely cheaper and faster.
Paul Eggert wrote:
> Ben Olasov <···@rctbank.ucsf.edu> writes:
>
> > I'm not sure how evaluate the trade-offs between more processors
> > vs. more memory, especially in terms of how it would affect Lisp
> > application performance.
>
> It depends on your Lisp application, but typically Lisp apps really
> like memory. You should consider adding memory no matter what you
> buy. Memory's cheap.
Well, I was hoping I could remain vague about this, but I can see I can't
get away with that here :-). The apps will use CL-HTTP, which absolutely
adores memory (at least in the incredibly inefficient ways I use it). As
for
implementation, the plan is to continue using ACL and hope that Franz and
the CL-HTTP people at MIT can find some way to keep working together...
> > Also, some general recommendations on which of the newer servers
> > would be good for Lisp work would be welcome.
>
> Assuming you have about $10-$15k to spend, if your apps will fit into
> 1 GB of RAM and you want the most sparc bang for your buck, you should
> consider buying a dozen Sun Netra X1s (US$995 each list), load them up
> with memory (probably $180 each to upgrade them to 1GB), and stick
> them into a grid.
>
> http://www.sun.com/software/grid/
>
> If your apps are larger or you must buy the more expensive 280R or Sun
> Blade 1000 for some reason, then you should consider waiting for the
> 1.05 GHz units scheduled for early next year.
Putting a dozen Netras together in a grid sounds like a really interesting
idea,
but the applications will be huge and there's no definite limit on how
much memory
they'll need later.
> http://www.sun.com/smi/Press/sunflash/2001-11/sunflash.20011119.2.html
I didn't know about this, thanks.
> or at least get the 900 MHz units available now. Personally I
> wouldn't bother with the Sun Blade 1000 unless you need a workstation.
>
> Just curious, though: why not use x86 hardware? If your app is
> CPU-bound and fits in 32 bits, x86 is most likely cheaper and faster.
Ben Olasov <·······@pacbell.net> writes:
> The apps will use CL-HTTP, which absolutely adores memory (at least
> in the incredibly inefficient ways I use it). As for
> implementation, the plan is to continue using ACL and hope that
> Franz and the CL-HTTP people at MIT can find some way to keep
> working together...
Is ACL multithreaded? If you are basically talking about a
unithreaded app, the extra processors won't help you much.
If sparc is required and you just have a uniprocessor app, then maybe
you should get a Sun Blade 1000 after all. It's currently the
cheapest way to get a system from Sun that has a 900 MHz processor.
($10,995 US list)
Add 4 GB of 3rd party RAM (8x 512 MB DIMMS, maybe $2400) and you're
still within the budget I hypothesized for you. The box will go up to
8 GB, but prices are still too high for the 1 GB DIMMs that you'll
need to get you there.
Paul Eggert wrote:
> Is ACL multithreaded?
Yes it is, and we do make a fair amount of use of multithreading.
> If you are basically talking about a
> unithreaded app, the extra processors won't help you much.
Part of the reason for considering the 280R is an educational promotion
Sun is running:
http://krusty.uen.org/prices/promos.html
Btw, I just heard from Sun that they can upgrade the 750MHz chip to the
1.05GHz when it becomes available.
Ben
Ben Olasov <····@rctbank.ucsf.edu> writes:
> > Is ACL multithreaded?
> Yes it is, and we do make a fair amount of use of multithreading.
OK, but the question is whether the OS-level multithreading works well.
(User-level threads don't count, of course.)
> Part of the reason for considering the 280R is an educational promotion
> Sun is running:
> http://krusty.uen.org/prices/promos.html
If you have to buy from that list and don't care too much about server
versus workstation, I would get the Sun Blade 1000 model 2750 ($9k)
and buy another 4 GB RAM from a 3rd party ($2400 last time I checked).
This'll be cheaper than $15k that they want for the 280R (plus you'll
get a decent display :-).
If you're willing to go with a clone or really want a server or both,
the Tatung U1000R <http://www.tsti.com/u280.html> might be a better
deal for you. We've used the related Tatung U280R5 model in a
production database server where the client was in too much of a hurry
to wait for a backordered Sun 280R.
Ben Olasov <·······@pacbell.net> wrote in message news:<·················@pacbell.net>...
> get away with that here :-). The apps will use CL-HTTP, which absolutely
> adores memory (at least in the incredibly inefficient ways I use it). As
> for
> implementation, the plan is to continue using ACL and hope that Franz and
> the CL-HTTP people at MIT can find some way to keep working together...
>
Unless things have changed, ACL is single-threaded in the sense that
its threads will not use more than one processor (this is true of all
current CLs I think). So unless you have more than one CL image you
don't significantly win from a multiporocesor. You may win if you
have other applications which can usefully get scheduled on other CPUs
(for instance if you're running CL-HTTP behind an apache proxy or
something). I *think* that ACL is now 64bit on the sparc (Maybe Duane
can comment?), so in that case, if your applications really are large
you probably want to consider a box you can put a lot of memory into,
which I think rules out netra X1s.
Unless you are doing *lots* of computation per request, things will
likely be I/O-bound I should think, with almost any modern machine, so
you want to look at something with decent I/O.
One thing to consider is that you can get quite good deals on
second-user machines right now, and some of these are pretty nice. I
recently saw an E3000 with 4CPUs and 6Gb of memory for about 3-4000
pounds. Total cost including a bunch of disks and some ethernet cards
would have been sub-10k. That's not a really fast machine by today's
standards, but it has a lot of memory which is likely to matter more.
--tim
--------------3F6A77F58ACC72565AB564BF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> Unless things have changed, ACL is single-threaded in the sense that
> its threads will not use more than one processor (this is true of all
> current CLs I think). So unless you have more than one CL image you
> don't significantly win from a multiporocesor. You may win if you
> have other applications which can usefully get scheduled on other CPUs
> (for instance if you're running CL-HTTP behind an apache proxy or
> something). I *think* that ACL is now 64bit on the sparc (Maybe Duane
> can comment?), so in that case, if your applications really are large
> you probably want to consider a box you can put a lot of memory into,
> which I think rules out netra X1s.
Yes, true (at least for Suns) for now, but (as mentioned somewhere else in this thread)
Franz suggests that
in the future all ACL implementations will use the :os-threads model, although they're not
specific as to
when. So, one win from having a multiprocessor now would be not having to buy another
server when the :os-threads model is implemented, assuming that happens within the server's
useful life. Perhaps Duane could also comment about the safety of that assumption?
> Unless you are doing *lots* of computation per request, things will
> likely be I/O-bound I should think, with almost any modern machine, so
> you want to look at something with decent I/O.
>
> One thing to consider is that you can get quite good deals on
> second-user machines right now, and some of these are pretty nice. I
> recently saw an E3000 with 4CPUs and 6Gb of memory for about 3-4000
> pounds. Total cost including a bunch of disks and some ethernet cards
> would have been sub-10k. That's not a really fast machine by today's
> standards, but it has a lot of memory which is likely to matter more.
>
> --tim
--
Ben Olasov
Programmer/ Analyst
University of California, San Francisco
Department of Medicine Research
3333 California Street
Room 435
San Francisco, CA
USA 94118
--------------3F6A77F58ACC72565AB564BF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<blockquote TYPE=CITE>Unless things have changed, ACL is single-threaded
in the sense that
<br>its threads will not use more than one processor (this is true of all
<br>current CLs I think). So unless you have more than one CL image
you
<br>don't significantly win from a multiporocesor. You may win if
you
<br>have other applications which can usefully get scheduled on other CPUs
<br>(for instance if you're running CL-HTTP behind an apache proxy or
<br>something). I *think* that ACL is now 64bit on the sparc (Maybe
Duane
<br>can comment?), so in that case, if your applications really are large
<br>you probably want to consider a box you can put a lot of memory into,
<br>which I think rules out netra X1s.</blockquote>
Yes, true (at least for Suns) for now, but (as mentioned somewhere else
in this thread) Franz suggests that
<br>in the future all ACL implementations will use the :os-threads model,
although they're not specific as to
<br>when. So, one win from having a multiprocessor now would be not
having to buy another server when the :os-threads model is implemented,
assuming that happens within the server's useful life. Perhaps Duane
could also comment about the safety of that assumption?
<blockquote TYPE=CITE>Unless you are doing *lots* of computation per request,
things will
<br>likely be I/O-bound I should think, with almost any modern machine,
so
<br>you want to look at something with decent I/O.
<p>One thing to consider is that you can get quite good deals on
<br>second-user machines right now, and some of these are pretty nice.
I
<br>recently saw an E3000 with 4CPUs and 6Gb of memory for about 3-4000
<br>pounds. Total cost including a bunch of disks and some ethernet
cards
<br>would have been sub-10k. That's not a really fast machine by
today's
<br>standards, but it has a lot of memory which is likely to matter more.
<p>--tim</blockquote>
<pre>--
Ben Olasov
Programmer/ Analyst
University of California, San Francisco
Department of Medicine Research
3333 California Street
Room 435
San Francisco, CA
USA 94118</pre>
</html>
--------------3F6A77F58ACC72565AB564BF--
Ben Olasov <···@rctbank.ucsf.edu> writes:
> Unless things have changed, ACL is single-threaded in the sense that
> its threads will not use more than one processor (this is true of all
> current CLs I think).� So unless you have more than one CL image you
> don't significantly win from a multiporocesor.� You may win if you
> have other applications which can usefully get scheduled on other CPUs
> (for instance if you're running CL-HTTP behind an apache proxy or
> something).� I *think* that ACL is now 64bit on the sparc (Maybe Duane
> can comment?),
The answer to Tim's question is that you can get either a 32-bit or
a 64-bit version for the sparc. I didn't originally answer it because
it is pretty easy to see on our website:
http://www.franz.com/products/
> so in that case, if your applications really are large
> you probably want to consider a box you can put a lot of memory into,
> which I think rules out netra X1s.
>
> Yes, true (at least for Suns) for now, but (as mentioned somewhere else
> in this thread) Franz suggests that in the future all ACL implementations
> will use the :os-threads model, although they're not specific as to
> when.� So, one win from having a multiprocessor now would be not having
> to buy another server when� the :os-threads model is implemented, assuming
> that happens within the server's useful life.� Perhaps Duane could also
> comment about the safety of that assumption?
It is always dangerous to ask me about the future, because I don't know
it (if I did, I'd be rich :-). All projects we have have at Franz Inc.
are either externally funded or internally funded. Externally funded
projects always carry extra weight. And for those internally funded
projects, we have to prioritize them and keep those priorities under
constant review. And sometimes the priorities change to make room for
new ideas or thrusts - the simple-streams design is a good example of
a project that took up a lot of my time and the time of several other
developers, at the expense of some other projects I was working on and
also considered important. However, now that simple-streams is done
and deployed, I am glad we made that choice.
As for :os-threads, it is true that we would like to port these to at
least some major platforms, but since again this is an internally
funded project, I can't possibly say what the time frame will be.
It could be that someone decides to fund the project and it will thus
get top priority for release very soon. Or perhaps someone will fund
a competing project, and we will continue to plod along slowly at lower
priority with this project.
Meanwhile, though, it's not as if we've been standing still on the issue
of multiple-processor usage - you can make good use of your multiprocessor
system _now_ by using our new LispRPC package:
http://www.franz.com/products/connectivity_tools/
In this situation, you have two lisps communicating with each other,
presmably running on separate processors. It's lighter weight than our
Corba interface, and results from the experience we've had in working
on Communications tools between Lisp and Java.
Happy Holidays to all.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Ben Olasov <·······@pacbell.net> writes:
> get away with that here :-). The apps will use CL-HTTP, which absolutely
> adores memory (at least in the incredibly inefficient ways I use it).
My experience with CL-HTTP on SPARC is that you can do quite a lot
within 50MB of RAM with one CL-HTTP process, even with a quite high
load (i.e. lots of lw processes inside it). But of course, I don't
know the memory requirements of _your_ part of the application.
In general, since (on Suns) neither ACL (still, I think) nor LispWorks
use OS threads, so if your application _has_ to be single-process,
your main means of increasing performance is faster processors and
more memory, not many processors (2 processors is always useful).
If, however, you can distribute your application on several CL-HTTP
images (if, for instance, you don't have to put all users inside the
same server, as long as you keep each individual user within the same
server), consider buying a stack of the cheap new small Sun servers and
put a Foundry Server Iron switch in front of it (or if that's a bit
too expensive, simply run several cl-http's and distribute with
either DNS round-robin entries or use one of the cl-http servers
as a redirecting server for the others).
Our main Sun server for lisp applications, which runs 4 big lisp
server applications (3 of them has had up to 100 internal lw
processes) and several dozens of small helper servers written in C,
has until very recently been a very modest Sun: A Sun Ultra Enterprise
2 with 1GB of RAM and 2 296Mhz Ultra-II processors. It only occasionally
had a load > 1.
--
(espen)
Espen Vestre wrote:
> In general, since (on Suns) neither ACL (still, I think) nor LispWorks
> use OS threads, so if your application _has_ to be single-process,
> your main means of increasing performance is faster processors and
> more memory, not many processors (2 processors is always useful).
Yes, this is true, at least of v5.01 which we use. From what I read in the
ACL multiprocessing docs though, not necessarily later:
"Release 5.0 of Allegro CL on Windows uses the :os-threads model. Allegro CL
on all Unix platforms uses the non :os-threads model. Earlier releases of
Allegro CL on Windows did not implement multiprocessing. Earlier releases on
Unix used the non :os-threads model, as they still
do. It is expected over time that all versions will adopt the :os-threads
model."
> If, however, you can distribute your application on several CL-HTTP
> images (if, for instance, you don't have to put all users inside the
> same server, as long as you keep each individual user within the same
> server), consider buying a stack of the cheap new small Sun servers and
> put a Foundry Server Iron switch in front of it (or if that's a bit
> too expensive, simply run several cl-http's and distribute with
> either DNS round-robin entries or use one of the cl-http servers
> as a redirecting server for the others).
We actually need to dedicate a port to each user. We run a separate cl-http
process for each port , redirect users to the next available port and use a
port scavenger process to bump idle users.
> Our main Sun server for lisp applications, which runs 4 big lisp
> server applications (3 of them has had up to 100 internal lw
> processes) and several dozens of small helper servers written in C,
> has until very recently been a very modest Sun: A Sun Ultra Enterprise
> 2 with 1GB of RAM and 2 296Mhz Ultra-II processors. It only occasionally
> had a load > 1.
That's good to know. I think the load problem we face comes mostly from using
cl-http as a web interface for collecting and presenting content in some large
knowledge bases. Later these kbs will be merged and the Sun server we use for
this now has such a small capacity it's hard to even run tests to predict how
much memory will be needed to do this.
> --
> (espen)
So far nobody in this discussion mentioned the tagged addition
instructions that SPARC has specifically to accelerate LISP.
Do they help at all, relatively to other CPUs?
-- Pete
·······@yahoo.com (Pete Zaitcev) writes:
> So far nobody in this discussion mentioned the tagged addition
> instructions that SPARC has specifically to accelerate LISP.
> Do they help at all, relatively to other CPUs?
Sort of. It was a good idea, but the designers of the 64-bit
extensions messed it up (and deprecated the original instructions,
to boot). We have discussed this in other threads in c.l.l and
in comp.arch.
However, taddcc is not the architecture innovation that would
revolutionize Common Lisp on general-purpose hardware; it's not
used enough to cause significantly different performance. I've
asked the people on comp.arch to instead give us a fast user-level
trap on any hardware, and that is one architecture feature that
would allow many GC'able languages to significantly improve
their heap management, and thus increase speed significantly,
including making true SMP or NUMA multiple-processor operations
more feasible in these gc'able languages without slowing them
down for software or hardware read/write barriers. It's probably
a pipe dream, though ...
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> asked the people on comp.arch to instead give us a fast user-level
> trap on any hardware, and that is one architecture feature that
> would allow many GC'able languages to significantly improve
> their heap management, and thus increase speed significantly,
> including making true SMP or NUMA multiple-processor operations
> more feasible in these gc'able languages without slowing them
> down for software or hardware read/write barriers. It's probably
> a pipe dream, though ...
VIA type architectures like Infiniband support user level DMA. I guess
similar types of mechanisms (e.g. protection keys and inbound/outbound
mapping tables in hardware) could provide a user level trap as well.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.com
In article <·················@rctbank.ucsf.edu>, Ben Olasov wrote:
> Hi,
>
> We're looking at adding a new Sun server that would primarily be used
> for developing and running Lisp apps. One of the choices is between a
> Sun Fire 280 R with two 750MHz UltraSPARC-III processors/ 2GB memory and
> a Sun Blade 1000 Workstation Model 1750 with one 750 MHz UltraSPARC III
> Processor /4GB Memory. I'm not sure how evaluate the trade-offs between
> more processors vs. more memory, especially in terms of how it would
> affect Lisp application performance. Can anyone shed some light on
> this? Also, some general recommendations on which of the newer servers
> would be good for Lisp work would be welcome.
>
> Thanks,
>
> Ben
I'm relatively new to Lisp, but I don't think that this is really a Lisp
question. It should have more to do with the apps you have, and how many
developers and users will be on at one time.
For instance, having a pile of developers on the system, each with their own
Lisp development environment, will be stressful on RAM in general. Still, it
depends on what they're doing, and how they're doing it. What problem space
would the apps apply to? If the application tends to be memory-bound, then
that will have an even greater effect with multiple developers.
In contrast, a production application, with one instance serving many users,
might instead be more CPU-bound, with each user only needing a bit of
additional memory, and most resources shared.
Finally, what are the upgrade paths for the two servers mentioned? If
perhaps you only need 1 CPU and 2GB of RAM, then either would be fine for
now, but the difference would be in what you can add when you have a better
idea of your requirements.
> In article <·················@rctbank.ucsf.edu>, Ben Olasov wrote:
> > We're looking at adding a new Sun server that would primarily be used
> > for developing and running Lisp apps. One of the choices is between a
> > Sun Fire 280 R with two 750MHz UltraSPARC-III processors/ 2GB memory and
> > a Sun Blade 1000 Workstation Model 1750 with one 750 MHz UltraSPARC III
> > Processor /4GB Memory. I'm not sure how evaluate the trade-offs between
> > more processors vs. more memory, especially in terms of how it would
> > affect Lisp application performance. Can anyone shed some light on
> > this? Also, some general recommendations on which of the newer servers
> > would be good for Lisp work would be welcome.
> >
> > Thanks,
> >
> > Ben
Tim Lavoie <········@spamcop.net> wrote in message
······················@news1.mts.net...
> I'm relatively new to Lisp, but I don't think that this is really a Lisp
> question. It should have more to do with the apps you have, and how many
> developers and users will be on at one time.
me too - new
BUT which implementation of Lisp?
I'm trying to get CMUCL running on my SS2, which is a far cry from your
boxes
but CMUCL only has MP (MultiProcessing) extensions for x86.
---
God I miss having a room full of dual E450's to play with (3 years ago)
gotta upgrade to either an SMP SS20 -or- what's a good used Ultra? (-1?)
Ben Olasov <···@rctbank.ucsf.edu> writes:
> We're looking at adding a new Sun server that would primarily be used
> for developing and running Lisp apps. One of the choices is between a
> Sun Fire 280 R with two 750MHz UltraSPARC-III processors/ 2GB memory and
> a Sun Blade 1000 Workstation Model 1750 with one 750 MHz UltraSPARC III
> Processor /4GB Memory. I'm not sure how evaluate the trade-offs between
> more processors vs. more memory, especially in terms of how it would
> affect Lisp application performance. Can anyone shed some light on
> this? Also, some general recommendations on which of the newer servers
> would be good for Lisp work would be welcome.
It depends on your Lisp applications, i.e. if you do mostly floating
point calculations, memory bound etc. In most cases you're probably
better off buying 10 similarly configured PC's... Last time I checked
a SUN Blade 1000 was 20k$ here in Europe.
Check out www.spec.org for benchmarks. A SUN Blade 1000 model 900 Cu
has a cint2000 of 533�. An AMD XP 1900+ (Epox 8KHA+ Motherboard) has
701. Of course the large (8MB) caches of the UltraSPARC III CPU might
result in better Lisp performance.
Petter
�) A SUN SS20 has a performance of 1 if memory serves me correctly
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.com
Petter Gustad wrote:
> It depends on your Lisp applications, i.e. if you do mostly floating
> point calculations, memory bound etc. In most cases you're probably
> better off buying 10 similarly configured PC's... Last time I checked
> a SUN Blade 1000 was 20k$ here in Europe.
>
> Check out www.spec.org for benchmarks. A SUN Blade 1000 model 900 Cu
> has a cint2000 of 533�. An AMD XP 1900+ (Epox 8KHA+ Motherboard) has
> 701. Of course the large (8MB) caches of the UltraSPARC III CPU might
> result in better Lisp performance.
I'd think spec benchmarks are not necessarily very reliable for
estimating Lisp performance.
- At least I was a few years back in a situation where we had a 85 MHz
SparcStation 5 outrunning a 180 MHz PentiumPro, both running the same
application using ACL 4.3.something, same amount of RAM on both. From
their SPEC data the situation should have been the other way round.
--
Martti Halminen <···············@kolumbus.fi> writes:
> Petter Gustad wrote:
>
> > It depends on your Lisp applications, i.e. if you do mostly floating
> > point calculations, memory bound etc. In most cases you're probably
> > better off buying 10 similarly configured PC's... Last time I checked
> > a SUN Blade 1000 was 20k$ here in Europe.
> >
> > Check out www.spec.org for benchmarks. A SUN Blade 1000 model 900 Cu
> > has a cint2000 of 533�. An AMD XP 1900+ (Epox 8KHA+ Motherboard) has
> > 701. Of course the large (8MB) caches of the UltraSPARC III CPU might
> > result in better Lisp performance.
>
> I'd think spec benchmarks are not necessarily very reliable for
> estimating Lisp performance.
I would *guess* Lisp performance would gain a lot from good integer
performance (unless your app is doing lots of fp calculations) and
large caches.
A very important factor is the actual Lisp implementation to be used,
i.e. if it's heavily optimized for the UltraSparc or the X86
architecture. I see very knowledgeable people from Franz here and over
in comp.arch who know about these issues...
> - At least I was a few years back in a situation where we had a 85 MHz
> SparcStation 5 outrunning a 180 MHz PentiumPro, both running the same
> application using ACL 4.3.something, same amount of RAM on both. From
> their SPEC data the situation should have been the other way round.
What OS did you run on the Intel system? Like I said it depends on the
ACL implementation for the respective OS and processor at the time.
I can't find the SPECint95 for a 85 MHz SPARCstation 5, I can only
find the SPARCstation 5 Model 170, which has 512KB level 2 cache. Most
Pentium Pro 180 systems shipped with a 256KB level 2 cache.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.com
Petter Gustad wrote:
> A very important factor is the actual Lisp implementation to be used,
> i.e. if it's heavily optimized for the UltraSparc or the X86
> architecture. I see very knowledgeable people from Franz here and over
> in comp.arch who know about these issues...
> > - At least I was a few years back in a situation where we had a 85 MHz
> > SparcStation 5 outrunning a 180 MHz PentiumPro, both running the same
> > application using ACL 4.3.something, same amount of RAM on both. From
> > their SPEC data the situation should have been the other way round.
> What OS did you run on the Intel system? Like I said it depends on the
> ACL implementation for the respective OS and processor at the time.
Windows NT 4.0, so part of the difference may have been MS vs. Unix;
also this was about the first version of "real" ACL (instead of the old
Allegro for Windows product) running on NT, so it may have been less
well optimized.
--
On Fri, 14 Dec 2001, Martti Halminen wrote:
> Petter Gustad wrote:
>
> > It depends on your Lisp applications, i.e. if you do mostly floating
> > point calculations, memory bound etc. In most cases you're probably
> > better off buying 10 similarly configured PC's... Last time I checked
> > a SUN Blade 1000 was 20k$ here in Europe.
> >
> > Check out www.spec.org for benchmarks. A SUN Blade 1000 model 900 Cu
> > has a cint2000 of 533¹. An AMD XP 1900+ (Epox 8KHA+ Motherboard) has
> > 701. Of course the large (8MB) caches of the UltraSPARC III CPU might
> > result in better Lisp performance.
>
> I'd think spec benchmarks are not necessarily very reliable for
> estimating Lisp performance.
> - At least I was a few years back in a situation where we had a 85 MHz
> SparcStation 5 outrunning a 180 MHz PentiumPro, both running the same
> application using ACL 4.3.something, same amount of RAM on both. From
> their SPEC data the situation should have been the other way round.
Why is this? The cache size? OS effeciency? I observe similar things,
however, between a G3/500 on Mac OS 9/X and a 1.3 GHz Athlon on Win2k..
G3 was at home, the Athlon at work. No AltiVec support on either the G3
or the app (Squeak). The SPEC benchmark would tell me that the Athlon
would beat the G4 hands down, but the G3 was keeping up better than I
expected. Curious.
Regards,
Aaron
Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/
"the question is no longer between violence and non-violence; It is
between non-violence and non-existence." :: martin luther king junior