Hello all,
does anyone here have any numbers on how well different lisps perform on
different x86-64 CPUs? Are Intels to be preferred for ClozureCL and LispWorks,
and Opterons best for SBCL and Scieneer for example?
--
Best regards,
Oyvin
�yvin Halfdan Thuv <·······@pvv.ntnu.no> writes:
> does anyone here have any numbers on how well different lisps perform on
> different x86-64 CPUs? Are Intels to be preferred for ClozureCL and LispWorks,
> and Opterons best for SBCL and Scieneer for example?
At least with our extremely unscientific (but good for our usage)
benchmark, Lispworks 64-bit runs almost twice as fast per GHz on Core
2 compared to Opteron. It's probably wise to make a benchmark out of
the most cpu-critical part(s) of your own code and try it out on
different systems (our results only apply to 64-bits linux, btw).
--
(espen)
On Nov 11, 9:47 pm, Espen Vestre <·····@vestre.net> wrote:
> It's probably wise to make a benchmark out of
> the most cpu-critical part(s) of your own code and try it out on
> different systems (our results only apply to 64-bits linux, btw).
This is really bad advice, sorry. Your benchmark should be the best
approximation to *your application* as it can possibly be. It's of no
interest, for instance, if the CPU-intensive 5% of the application's
time is 100 times faster while the I/O bound 95% is twice as slow: the
application is still basically twice as slow.
Tim Bradshaw <··········@tfeb.org> writes:
> This is really bad advice, sorry. Your benchmark should be the best
> approximation to *your application* as it can possibly be. It's of no
> interest, for instance, if the CPU-intensive 5% of the application's
> time is 100 times faster while the I/O bound 95% is twice as slow: the
> application is still basically twice as slow.
I agree, but I thought we were trying to isolate the discussion to
choosing the right cpu here, not really the rest of the system.
--
(espen)
On 2008-11-13, Espen Vestre <·····@vestre.net> wrote:
> Tim Bradshaw <··········@tfeb.org> writes:
>
>> This is really bad advice, sorry. Your benchmark should be the best
>> approximation to *your application* as it can possibly be. It's of no
>> interest, for instance, if the CPU-intensive 5% of the application's
>> time is 100 times faster while the I/O bound 95% is twice as slow: the
>> application is still basically twice as slow.
>
> I agree, but I thought we were trying to isolate the discussion to
> choosing the right cpu here, not really the rest of the system.
Yes, I was wondering about which CPU to choose. Thanks for the response.
I find it interesting that the two different CPUs perform /that/
different (in your app.).
--
Oyvin
�yvin Halfdan Thuv <·······@pvv.ntnu.no> writes:
> Yes, I was wondering about which CPU to choose. Thanks for the response.
> I find it interesting that the two different CPUs perform /that/
> different (in your app.).
Yes, it's pretty strange. The old (pre Core 2, i.e. P4-based) Xeons
were a disaster for lisp, but I think that was easy to explain with
the long pipeline of the P4 architecture, but the Opterons and Core 2s
are not so different in that respect, AFAIK. With the next processor,
the Core i7, Intel is into long pipelines again, so maybe AMD will be
the best for lisp in a few months...
--
(espen)
Espen Vestre <·····@vestre.net> writes:
>�yvin Halfdan Thuv <·······@pvv.ntnu.no> writes:
>> Yes, I was wondering about which CPU to choose. Thanks for the response.
>> I find it interesting that the two different CPUs perform /that/
>> different (in your app.).
>Yes, it's pretty strange. The old (pre Core 2, i.e. P4-based) Xeons
>were a disaster for lisp, but I think that was easy to explain with
>the long pipeline of the P4 architecture, but the Opterons and Core 2s
>are not so different in that respect, AFAIK. With the next processor,
>the Core i7, Intel is into long pipelines again, so maybe AMD will be
>the best for lisp in a few months...
And it depends where the memory controller is and the latency for
your typical Lisp applications.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
The port to X86_64 is quite recent for every CL implementation,
therefore a little early to state anything conclusive. I mean... in 4
months time things could be completely different than today, but you
could find yourself already stuck with your choice of implementation.
These are my general rules of thumb (do not take them too seriously)
1- Always go for free software. 2-If you don't need threads, go for
CLISP. 3- If you need threads, choose CCL or SBCL based on this: CCL
does not achieve performance at the cost of great memory consumption
like SBCL seems to do.