New 64 bit computers
CCamp81318
appreciate it if they would tell me how many nodes per second Fritz 7 or
Shredder 7 process on these computers.
Thanks in advance
Noah Roberts
I am getting an AMD64 very soon. Supposed to arrive tomarro but I won't
be here to pick it up :P
AFAIK it would be pointless running either Fritz 7 or Shredder 7 on this
machine as neither one will utilize the 64 bit registers. They would
need to be recompiled and the OS would have to be running in 64 bit mode
instead of legacy mode. I won't be having a 64 bit version of windows.
Basically it would be just like running on a 32 bit computer.
If someone wants to supply me with copies of these engines I would post
results, but I would not expect them to be very interesting.
However, if there is interest I would be willing to post results of
operations from crafty, gnuchess, or any other OS bitboard engine. OS
is of course required as I will have to recompile. It must also run on
Linux.
I plan on utilizing the SSE2 registers in this machine to build my own
engine for chinese chess, which requires 90 bit bitboards.
NR
Dr. David Kirkby
<soapbox>
There is a lot of hype about 64-bits. I believe 'crafty' is basically
a 64-bit calculator, so would in principle at least run faster on
64-bits (I'm sure Robert will clarify matters).
But be aware that any references to memory ("pointers") take up 8
bytes on a 64-bit machine, compared to 4 on a 32-bit machine. So fewer
memory references can fit in the cache, so the cache hit rate goes
down.
I find the whole thing about 64-bit a bit of a joke really. One
magazine (Personal Computer World published in the UK) recently stated
that Apple were the first to put a 64-bit computer on the desktop.
That is total junk, as I know Sun did it nearly a decade earlier and I
don't think Sun were the first.
The machine I'm sending this message from is an oldish 64-bit computer
from Sun (Ultra 80, 4 x 450 MHz CPUs with 4 MB cache each, 4 GB RAM).
The operating system (Solaris 9) fully supports 64-bit hardware. Yet
if one checks how most of the executables are linked (using the UNIX
'file' command), one sees that most are in fact 32-bit, not 64-bit.
Sun do that for performance reasons - why make executables larger, and
get lower cache hit rates unless you need to ???
64-bit machines are neither new, nor any benifit at all, for the vast
majority of tasks. Chess might well be an exception to that (I think
it is), but before shelling out lots of $$$$'s for 64-bit machines,
check whether there is going to be any gain at all.
I know someone who built crafty on a 64-bit Sun and found some, but
quite a small benifit. In this case the SPARC assembly code, that
forms part of crafty, was written for 32-bit machines, so the main CPU
intensive bits don't benifit from 64-bits. No doubt if Sparc.s was
re-written to exploit 64-bit registers on Suns, crafty would run
faster, but that would not be a trivual task for anyone. On x86 I
guess more effort will be put into making 64-bit optimised versions.
Sun have rather lost their way in the workstation market.
Just a few thoughts - before you go out buying 64-bit hardware!
If you fancy playing with 64-bits, get yourself a Sun Ultra 1 on eBay.
This one sold for less than $30 !!!
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3064866384&category=20327
You can download Solaris 9 for free, although you are supposed to buy
a license after a 60-day trial period (not that it stops working or
anything).
64-bits is very hold hat - don't get caught up in all the hype
</soapbox>
Dr. David Kirkby PhD CEng MIEE
Anders Carlsson
> I find the whole thing about 64-bit a bit of a joke really.
Btw, wasn't it stated that Nintendo 64 uses a 64-bit processor, or
did they just count the wrong type of bits (address, data, ALU or
other bit measurement?).
> If you fancy playing with 64-bits, get yourself a Sun Ultra 1 on eBay.
Isn't the repertoaire of instructions, pipeline, cache and other
technologies more exciting than the size of each memory fetch? I
believe the new AMD and Intel technologies are quite different
from what Sun did many years ago.
But I agree, just as little as MHz is the single factor deciding a
computer's strength, bitness is too. Some time ago I read that Intel
got themselves in an AMD dilemma as the new Pentium M models are as
powerful as the old Pentium 4 but on lower frequencies, and had to
reconsider how to name them without being overlooked by customers.
--
Anders Carlsson
Ye wonder, she's thirteen beyond an invisible carefully preserved leather
mouse. Sunday dungeons promising horseback cause loud guessed scissors.
Dr. David Kirkby
> see_my_signature_f...@hotmail.com (Dr. David Kirkby) writes:
>
> > I find the whole thing about 64-bit a bit of a joke really.
>
> Btw, wasn't it stated that Nintendo 64 uses a 64-bit processor, or
> did they just count the wrong type of bits (address, data, ALU or
> other bit measurement?).
>
No mention of games consoles, although there is a big difference
between a general purpose computer and a games console. A later
article in Personal Comptuer World, which suffered some serious
errors, did mention games consoles.
> > If you fancy playing with 64-bits, get yourself a Sun Ultra 1 on eBay.
>
> Isn't the repertoaire of instructions, pipeline, cache and other
> technologies more exciting than the size of each memory fetch? I
> believe the new AMD and Intel technologies are quite different
> from what Sun did many years ago.
Personally I can't get that excited about any of it, but then I'm not
a computer scientist, and by the age of 40 have grown out of the
desire to have the latest and fastest computer.
But I do feel the computer industry is trying to make people think
they need 64-bit hardware, when in fact few do. Modern 32-bit machines
have performance far in excess of what most users need. Those playing
high-speed games (not like chess) are still going to need high-end
graphics cards, but that won't change if one uses a 32 or 64-bit CPU.
The point I'm trying to make is that before shelling out lots of money
for 64-bit hardware, operating system, user software, possibly
development software, make very sure you need it.
Dr. David Kirkby.
Robert Hyatt
> ccamp...@aol.com (CCamp81318) wrote in message news:<20031223090658...@mb-m01.aol.com>...
>> If anyone has and AMD 64 FX-51 or one of the new pentium 4 computers I would
>> appreciate it if they would tell me how many nodes per second Fritz 7 or
>> Shredder 7 process on these computers.
>>
>> Thanks in advance
> <soapbox>
> There is a lot of hype about 64-bits. I believe 'crafty' is basically
> a 64-bit calculator, so would in principle at least run faster on
> 64-bits (I'm sure Robert will clarify matters).
Yes. I have run on a 4-way opteron 2.0ghz machine. It has produced
the fastest Crafty NPS numbers I have seen from a 4-way machine. IE
I played quite a few games on ICC a couple of weeks ago using this
machine while doing some testing for AMD, and I saw game NPS numbers
from 7M to 11M, which is _really_ fast... My dual 2.8ghz xeon hits
about 2.4M for reference.
> But be aware that any references to memory ("pointers") take up 8
> bytes on a 64-bit machine, compared to 4 on a 32-bit machine. So fewer
> memory references can fit in the cache, so the cache hit rate goes
> down.
Maybe. Remember that on the opteron L2 cache is 1mb, as opposed to
512kb for the normal xeons. So it is a perfect wash since wordsize
and cache size are both doubled.
> I find the whole thing about 64-bit a bit of a joke really. One
> magazine (Personal Computer World published in the UK) recently stated
> that Apple were the first to put a 64-bit computer on the desktop.
> That is total junk, as I know Sun did it nearly a decade earlier and I
> don't think Sun were the first.
> The machine I'm sending this message from is an oldish 64-bit computer
> from Sun (Ultra 80, 4 x 450 MHz CPUs with 4 MB cache each, 4 GB RAM).
> The operating system (Solaris 9) fully supports 64-bit hardware. Yet
> if one checks how most of the executables are linked (using the UNIX
> 'file' command), one sees that most are in fact 32-bit, not 64-bit.
> Sun do that for performance reasons - why make executables larger, and
> get lower cache hit rates unless you need to ???
> 64-bit machines are neither new, nor any benifit at all, for the vast
> majority of tasks. Chess might well be an exception to that (I think
> it is), but before shelling out lots of $$$$'s for 64-bit machines,
> check whether there is going to be any gain at all.
> I know someone who built crafty on a 64-bit Sun and found some, but
> quite a small benifit. In this case the SPARC assembly code, that
> forms part of crafty, was written for 32-bit machines, so the main CPU
> intensive bits don't benifit from 64-bits. No doubt if Sparc.s was
> re-written to exploit 64-bit registers on Suns, crafty would run
> faster, but that would not be a trivual task for anyone. On x86 I
> guess more effort will be put into making 64-bit optimised versions.
> Sun have rather lost their way in the workstation market.
Actually the 64 bit stuff is easier to write than the 32 bit versions,
because the 32 bit version has to fiddle with two 32 bit words to do the
64 bit operations Crafty depends on. On the opteron, for example, the asm
was _very_ easy to write and debug (it took maybe an hour total to do).
> Just a few thoughts - before you go out buying 64-bit hardware!
I would agree for the general case. 64 bit machines provide two
benefits. If either is important, the 64 bit machine will run well:
1. 64 bit operations. For a bitboard program, this is significant since
most of the computation is based on fiddling with 64 bit words that represent
the states of the 64 chess board squares.
2. Larger memory. The opterons I used supported a 48 bit physical address
space. That means you can run up to four terabytes of RAM and use it all in
a single process. If you need to address more than 3+ gigabytes, then the
32 bit world leaves you panting as 2^32 = 4 gigabytes, and the O/S and
devices take a big chunk of that away from you.
> If you fancy playing with 64-bits, get yourself a Sun Ultra 1 on eBay.
> This one sold for less than $30 !!!
Or don't. Suns have _always_ been at the bottom of the food chain in
terms of performance, since the first sparc came out. We have some of
the latest ultra's here, and the PCs are blowing 'em out of the water,
both in price and performance. Best 64 bit machine you can buy today is
a single-cpu Opteron (aka FX51 or some such nonsense.)
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3064866384&category=20327
> You can download Solaris 9 for free, although you are supposed to buy
> a license after a 60-day trial period (not that it stops working or
> anything).
> 64-bits is very hold hat - don't get caught up in all the hype
> </soapbox>
I would agree. Alphas have been around for 10 years, as has MIPS, HP's PA,
IBM's PPC, the ultrasparc from Sun, not to forget Cray which was the first,
of course. :) But most of those are doing 64 bits poorly. The new AMD
stuff is _hot_ (in terms of performance, not power radiation).
> Dr. David Kirkby PhD CEng MIEE
--
Robert M. Hyatt, Ph.D. Computer and Information Sciences
hy...@uab.edu University of Alabama at Birmingham
(205) 934-2213 136A Campbell Hall
(205) 934-5473 FAX Birmingham, AL 35294-1170
Tommy
"Robert Hyatt" <hy...@crafty.cis.uab.edu> wrote
> > If you fancy playing with 64-bits, get yourself a Sun Ultra 1 on eBay.
> > This one sold for less than $30 !!!
>
> Or don't. Suns have _always_ been at the bottom of the food chain in
> terms of performance, since the first sparc came out. We have some of
> the latest ultra's here, and the PCs are blowing 'em out of the water,
> both in price and performance. Best 64 bit machine you can buy today is
> a single-cpu Opteron (aka FX51 or some such nonsense.)
I completely agree with you.
I just want to mention that there are also cheaper options from AMD.....
The single-cpu version of the Opteron, the Athlon FX51, is cheaper than the
Opteron (at same clock speed) of course
However the Athlon 64 is even cheaper than the Athlon FX51 and it is still
64 bits. It also plugs on different motherboards (754 pin) which in turn are
much cheaper than the 940pin (athlon fx51 and opteron).
Here in the UK the FX51 costs around 550 pounds while the Athlon 64 costs
around 315 (it also works 200mhz slower).
AMD recently decided to try and make their new 64 bit processors even more
popular by further reducing prices.
The result is the Athlon 64 "budget", in other words the 512KB cache
version.
This results in 4 different versions:
- Opteron*
- Athlon FX51
- Athlon 64
- Athlon 64 budget
* of course there are different versions of the opteron as well ;-)
The Athlon 64 is called "Athlon 64 3200+" the Athlon 64 budget is called
"Athlon 64 3000+" (they have the same clock speed). The latter one will cost
around half the price of the current Athlon 64 3200+.
This makes the difference in price between the Athlon FX51 and the Athlon 64
3000+ *huge*. (the latter will cost about 3 times less!)
As a result, the Athlon FX51 is of course the best 64-bit single-cpu on the
market, but maybe the Athlon 64 3000+ is better as far as the
performance/cost ratio is concerned.
There are already numerous benchamarks of all these different versions,
unfortunately it is impossible to find one that tests them all in a 64-bit
environment (they do it in 32-bit). What is more no one has yet tested the
Athlon 64 3000+ with crafty I guess.... and... the results would be
interesting.
Tommy
Dr. David Kirkby
> Dr. David Kirkby <see_my_signature_f...@hotmail.com> wrote:
> > <soapbox>
> > There is a lot of hype about 64-bits. I believe 'crafty' is basically
> > a 64-bit calculator, so would in principle at least run faster on
> > 64-bits (I'm sure Robert will clarify matters).
>
> Yes. I have run on a 4-way opteron 2.0ghz machine. It has produced
> the fastest Crafty NPS numbers I have seen from a 4-way machine. IE
> I played quite a few games on ICC a couple of weeks ago using this
> machine while doing some testing for AMD, and I saw game NPS numbers
> from 7M to 11M, which is _really_ fast... My dual 2.8ghz xeon hits
> about 2.4M for reference.
For comparision, on my quad 450 MHz UltraSPARC, it is doing ~ 550
kn/s, with the Sparc.s 32-bit assembler, using Sun's compiler.
When compiled as a true 64-bit application, without the 32-bit
assembler code:
cc -fast -xarch=v9a -xO5 -xunroll=20 -DCOMPACT_ATTACKS
-DUSE_ATTACK_FUNCTIONS -DSMP -DFAST -DCPUS=4 -DMUTEX -DPOSIX
-DSUN
it's about the same, so the 32-bit assembler seems no better or worst
than letting Sun's compiler do it with 64-bit instructions, which
surprises me a bit.
In any case, this machine is a little over an order of magnitude
slower than your quad processor 2 GHz Opteron!!
For some reason, the 64-bit executable is about half the size of the
32-bit one, which did rather surprise me.
sparrow /usr/local/bin # ls -lrt crafty*
-rwxr-xr-x 1 root bin 3655808 Dec 17 13:15 crafty32
-rwxr-xr-x 1 root bin 1525872 Dec 31 15:52 crafty64
lrwxrwxrwx 1 root other 8 Dec 31 15:53 crafty ->
crafty64
> > But be aware that any references to memory ("pointers") take up 8
> > bytes on a 64-bit machine, compared to 4 on a 32-bit machine. So fewer
> > memory references can fit in the cache, so the cache hit rate goes
> > down.
>
> Maybe. Remember that on the opteron L2 cache is 1mb, as opposed to
> 512kb for the normal xeons. So it is a perfect wash since wordsize
> and cache size are both doubled.
I assume though that if you used an OS that allows both 32 and 64-bit
executables to be compiled, you could gain from the larger cache,
whilst still keeping the pointers smaller. I believe that is Sun's
logic for compiling most applications as 32-bit on a 64-bit OS. The
CPUs in here each have 4 MB of cache. Clearly this is not a start of
the art system, but it does all I want.
> > I know someone who built crafty on a 64-bit Sun and found some, but
> > quite a small benifit. In this case the SPARC assembly code, that
> > forms part of crafty, was written for 32-bit machines, so the main CPU
> > intensive bits don't benifit from 64-bits. No doubt if Sparc.s was
> > re-written to exploit 64-bit registers on Suns, crafty would run
> > faster, but that would not be a trivual task for anyone. On x86 I
> > guess more effort will be put into making 64-bit optimised versions.
> > Sun have rather lost their way in the workstation market.
> Actually the 64 bit stuff is easier to write than the 32 bit versions,
> because the 32 bit version has to fiddle with two 32 bit words to do the
> 64 bit operations Crafty depends on. On the opteron, for example, the asm
> was _very_ easy to write and debug (it took maybe an hour total to do).
That I'm sure is true, but you wrote the code in the first place, so
you understand it.
I briefly looked at Sparc.s, with a view to perhaps re-writing it to
use 64-bit instructions. Whilst I knew you were using the 32-bit
instructions to do something that would better be done in 64-bit,
there is no way I was going to be able to work out how to convert it.
About the only thing I could obviously do was to align on 8-byte
memory addresses rather than 4. Anything beyond that requires quite a
bit of work to convert for someone that:
a) Does not know the source code.
b) Does not know SPARC assembler, but has done quite a bit of x86 &
x87 assembler.
c) Does have a book on SPARC assembly language programming, that he
bought used and has never opened! (The book was probably written
before the 64-bit machines, but I doubt that makes a lot of odds).
If you ever do make a 64-bit version of Sparc.s, let me know. My
approach in the past to produce x86 assembler code has been to compile
the C source, look at the assembler, then optimise it. I've no idea
how practical that approach would be with crafty.
> > Just a few thoughts - before you go out buying 64-bit hardware!
>
> I would agree for the general case. 64 bit machines provide two
> benefits. If either is important, the 64 bit machine will run well:
>
> 1. 64 bit operations. For a bitboard program, this is significant since
> most of the computation is based on fiddling with 64 bit words that represent
> the states of the 64 chess board squares.
Yes, I accept that, but again not many applications benifit from that.
> 2. Larger memory. The opterons I used supported a 48 bit physical address
> space. That means you can run up to four terabytes of RAM and use it all in
> a single process. If you need to address more than 3+ gigabytes, then the
> 32 bit world leaves you panting as 2^32 = 4 gigabytes, and the O/S and
> devices take a big chunk of that away from you.
There are ways of addressing more than 4 GB on machines based on
32-bit CPUs. Some Pentium PCs will take 8 GB of RAM. But no single
process can be over 4GB. But again, few people need that.
> > If you fancy playing with 64-bits, get yourself a Sun Ultra 1 on eBay.
> > This one sold for less than $30 !!!
>
> Or don't. Suns have _always_ been at the bottom of the food chain in
> terms of performance, since the first sparc came out. We have some of
> the latest ultra's here, and the PCs are blowing 'em out of the water,
> both in price and performance. Best 64 bit machine you can buy today is
> a single-cpu Opteron (aka FX51 or some such nonsense.)
My comment was rather flippant. Perhaps I should have stated that I'm
well aware the a 64-bit 170 MHz Sun Ultra 1, which I know can't even
take 4 GB of RAM, is likely to have less than 5% of the performance of
a modern PC.
But Suns are the cheapest 64-bit machines around. Even an old Dec
Alpha, HP PA-RISC, SGI Octane (all 64-bit, and all of which I own),
will cost more than $30 used on eBay. I was just trying to make the
point that 64-bit CPUs are not a new thing, and the early ones are so
obsolete that the particular one I pointed out fetched only $30. Here
in the UK prices are quite a bit higher for UNIX hardware.
> > 64-bits is very hold hat - don't get caught up in all the hype
> > </soapbox>
>
> I would agree. Alphas have been around for 10 years, as has MIPS, HP's PA,
> IBM's PPC, the ultrasparc from Sun, not to forget Cray which was the first,
> of course. :) But most of those are doing 64 bits poorly. The new AMD
> stuff is _hot_ (in terms of performance, not power radiation).
I know you have a lot of experience of Cray supercomputers, but for
anyone that wants to use one, you can get a free account on a 4-CPU
Cray Y-MP EL at
http://www.cray-cyber.org/general/start.php
Just don't bother unless you like watching paint dry, as the
performance is really really sloooooooow by today's standards. A
benchmark I run using some floating point CPU intensive code of mine
took just over an hour on the old Cray, yet just 28 s on a dual CPU
Itanium. To be fair, the code was not in any way optimised for the
Cray's vector processors, whereas it was multi-threaded to exploit the
dual CPUs of the Itanium.
PS, Did you get the email I sent you giving a link to my first attempt
at converting crafty to use autoconf/automake, rather than the
Makefile ?
Dr. David Kirkby
Thomas T. Veldhouse
> The point I'm trying to make is that before shelling out lots of money
> for 64-bit hardware, operating system, user software, possibly
> development software, make very sure you need it.
>
> Dr. David Kirkby.
This is true, however this is one advantage that is being over looked. I
believe address mapping on a 32-bit machine limits memory to 4GB. Methods
to get around this exist of course, as they did back in the 16-bit days and
before. A 64-bit address space should end size limitations like this for a
very long time.
Tom Veldhouse
CCamp81318
will repeat my question. How many nodes per second does either Fritz 7 or
Shredder 7 evaluate when ran on an AMD 64 FX-51 or one of the new 64 bit
pentium chips. This is the specific information that I am looking for and all
off topic posts are a hinderance.
Thanks in advance to anyone that actually answers my question.
CT
Robert Hyatt
> Robert Hyatt <hy...@crafty.cis.uab.edu> wrote in message news:<bste38$5sm$3...@juniper.cis.uab.edu>...
>> Dr. David Kirkby <see_my_signature_f...@hotmail.com> wrote:
>> > <soapbox>
>
>> > There is a lot of hype about 64-bits. I believe 'crafty' is basically
>> > a 64-bit calculator, so would in principle at least run faster on
>> > 64-bits (I'm sure Robert will clarify matters).
>>
>> Yes. I have run on a 4-way opteron 2.0ghz machine. It has produced
>> the fastest Crafty NPS numbers I have seen from a 4-way machine. IE
>> I played quite a few games on ICC a couple of weeks ago using this
>> machine while doing some testing for AMD, and I saw game NPS numbers
>> from 7M to 11M, which is _really_ fast... My dual 2.8ghz xeon hits
>> about 2.4M for reference.
> For comparision, on my quad 450 MHz UltraSPARC, it is doing ~ 550
> kn/s, with the Sparc.s 32-bit assembler, using Sun's compiler.
OK. On my one+ year old dual xeon 2.8, it is running about 2.4M
nodes per second, using Intel's C compiler for linux.
> When compiled as a true 64-bit application, without the 32-bit
> assembler code:
> cc -fast -xarch=v9a -xO5 -xunroll=20 -DCOMPACT_ATTACKS
> -DUSE_ATTACK_FUNCTIONS -DSMP -DFAST -DCPUS=4 -DMUTEX -DPOSIX
> -DSUN
> it's about the same, so the 32-bit assembler seems no better or worst
> than letting Sun's compiler do it with 64-bit instructions, which
> surprises me a bit.
> In any case, this machine is a little over an order of magnitude
> slower than your quad processor 2 GHz Opteron!!
right. That's the kind of numbers I have seen here on our sparcs. It
makes me want to puke. :)
> For some reason, the 64-bit executable is about half the size of the
> 32-bit one, which did rather surprise me.
> sparrow /usr/local/bin # ls -lrt crafty*
> -rwxr-xr-x 1 root bin 3655808 Dec 17 13:15 crafty32
> -rwxr-xr-x 1 root bin 1525872 Dec 31 15:52 crafty64
> lrwxrwxrwx 1 root other 8 Dec 31 15:53 crafty ->
> crafty64
Might be some library issues involved there.
>
>> > But be aware that any references to memory ("pointers") take up 8
>> > bytes on a 64-bit machine, compared to 4 on a 32-bit machine. So fewer
>> > memory references can fit in the cache, so the cache hit rate goes
>> > down.
>>
>> Maybe. Remember that on the opteron L2 cache is 1mb, as opposed to
>> 512kb for the normal xeons. So it is a perfect wash since wordsize
>> and cache size are both doubled.
> I assume though that if you used an OS that allows both 32 and 64-bit
> executables to be compiled, you could gain from the larger cache,
> whilst still keeping the pointers smaller. I believe that is Sun's
> logic for compiling most applications as 32-bit on a 64-bit OS. The
> CPUs in here each have 4 MB of cache. Clearly this is not a start of
> the art system, but it does all I want.
Actually on the Opteron, you can still do 32 bit stuff. In fact, you
can use registers like %al for 8 bit stuff, %ax for 16 bit stuff,
%eax for 32 bit stuff, and %rax for 64 bit stuff. And, in theory, you
can do 32 bit pointers, although if you run in 64 bit mode, you need to
extend them to 64 bit values when they get sucked into registers...
One common place is to map a file into your address space. If your
address space is limited to 4 gigs, you can't map big files in. With
a 64 bit address, you can map in a _lot_. :)
IE you can't build 6 piece endgame tables using Eugene's code, without
a 64 bit machine, because of this.
> http://www.cray-cyber.org/general/start.php
Yes. But I've been in and out for the last week, with Christmas, etc going
on. I will be "back in the saddle" on Monday...
> Dr. David Kirkby
Simon Waters
>
> I know you have a lot of experience of Cray supercomputers, but for
> anyone that wants to use one, you can get a free account on a 4-CPU
> Cray Y-MP EL at
>
> http://www.cray-cyber.org/general/start.php
>
> Just don't bother unless you like watching paint dry, as the
> performance is really really sloooooooow by today's standards. A
> benchmark I run using some floating point CPU intensive code of mine
> took just over an hour on the old Cray, yet just 28 s on a dual CPU
> Itanium. To be fair, the code was not in any way optimised for the
> Cray's vector processors, whereas it was multi-threaded to exploit the
> dual CPUs of the Itanium.
As the site says 460 MFlops or about the same as the 2.4GHz Pentium.
Your results sound way off this.
By default the Cray compiler didn't attempt any optimisation (bizarre I
know), so I would check your command line.
My experience of the YMP family was when it takes longer to optimise
than it does to run you've probably got the right set of optimisation
flags ;-). The optimiser was pig slow, but did the most fantastic job.
Fairly clean code tended to optimise "as is" on the Cray compiler. But
be aware we are discussing a time when these machines cost millions of
dollars, and it was assumed the users would take a key interest in
avoiding constructs that would break or slow optimisation.
At the time all my code was Fortran, I think it was the C90 compiler
that used the same back end optimiser for C and Fortran, how backwardly
compatible these tools were to older Crays I've no idea. People didn't
run old Crays, it wasn't cost effective once the machine was about 3
years old, as Cray hardware support was about 20% the (original!) value
of the hardware a year.
Dr. David Kirkby
> Dr. David Kirkby <see_my_signature_f...@hotmail.com> wrote:
> > Robert Hyatt <hy...@crafty.cis.uab.edu> wrote in message news:<bste38$5sm$3...@juniper.cis.uab.edu>...
> >> Dr. David Kirkby <see_my_signature_f...@hotmail.com> wrote:
> >> > <soapbox>
>
> > For comparision, on my quad 450 MHz UltraSPARC, it is doing ~ 550
> > kn/s, with the Sparc.s 32-bit assembler, using Sun's compiler.
>
> OK. On my one+ year old dual xeon 2.8, it is running about 2.4M
> nodes per second, using Intel's C compiler for linux.
I agree Sun have lost their way on performance. They really don't cut
the mustard any more for CPU intensive tasks. But to be fair this
machine is >> 1 year old. I don't know when it was introduced, but it
certainly not new.
> > In any case, this machine is a little over an order of magnitude
> > slower than your quad processor 2 GHz Opteron!!
>
> right. That's the kind of numbers I have seen here on our sparcs. It
> makes me want to puke. :)
As I say, it not new. I bought it used on eBay about 18 months ago.
> > For some reason, the 64-bit executable is about half the size of the
> > 32-bit one, which did rather surprise me.
>
> > sparrow /usr/local/bin # ls -lrt crafty*
> > -rwxr-xr-x 1 root bin 3655808 Dec 17 13:15 crafty32
> > -rwxr-xr-x 1 root bin 1525872 Dec 31 15:52 crafty64
> > lrwxrwxrwx 1 root other 8 Dec 31 15:53 crafty ->
> > crafty64
> Might be some library issues involved there.
Virtually all the libraries linked in are different, so that is quite
possible.
sparrow /export/home/davek/chess % ldd /usr/local/bin/crafty64
libpthread.so.1 => /usr/lib/64/libpthread.so.1
libm.so.1 => /usr/lib/64/libm.so.1
libc.so.1 => /usr/lib/64/libc.so.1
libdl.so.1 => /usr/lib/64/libdl.so.1
libthread.so.1 => /usr/lib/64/libthread.so.1
librt.so.1 => /usr/lib/64/librt.so.1
libaio.so.1 => /usr/lib/64/libaio.so.1
libmd5.so.1 => /usr/lib/64/libmd5.so.1
/usr/platform/SUNW,Ultra-80/lib/sparcv9/libc_psr.so.1
/usr/platform/SUNW,Ultra-80/lib/sparcv9/libmd5_psr.so.1
sparrow /export/home/davek/chess % ldd /usr/local/bin/crafty32
libpthread.so.1 => /usr/lib/libpthread.so.1
libm.so.1 => /usr/lib/libm.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libthread.so.1 => /usr/lib/libthread.so.1
librt.so.1 => /usr/lib/librt.so.1
libaio.so.1 => /usr/lib/libaio.so.1
libmd5.so.1 => /usr/lib/libmd5.so.1
/usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1
/usr/platform/SUNW,Ultra-80/lib/libmd5_psr.so.1
sparrow /export/home/davek/chess %
> > I assume though that if you used an OS that allows both 32 and 64-bit
> > executables to be compiled, you could gain from the larger cache,
> > whilst still keeping the pointers smaller. I believe that is Sun's
> > logic for compiling most applications as 32-bit on a 64-bit OS. The
> > CPUs in here each have 4 MB of cache. Clearly this is not a start of
> > the art system, but it does all I want.
>
> Actually on the Opteron, you can still do 32 bit stuff. In fact, you
> can use registers like %al for 8 bit stuff, %ax for 16 bit stuff,
> %eax for 32 bit stuff, and %rax for 64 bit stuff. And, in theory, you
> can do 32 bit pointers, although if you run in 64 bit mode, you need to
> extend them to 64 bit values when they get sucked into registers...
AL, AX amd EAX bring back old memories - ones I'd rather forget!
>
> > There are ways of addressing more than 4 GB on machines based on
> > 32-bit CPUs. Some Pentium PCs will take 8 GB of RAM. But no single
> > process can be over 4GB. But again, few people need that.
>
> One common place is to map a file into your address space. If your
> address space is limited to 4 gigs, you can't map big files in. With
> a 64 bit address, you can map in a _lot_. :)
> IE you can't build 6 piece endgame tables using Eugene's code, without
> a 64 bit machine, because of this.
True, but not many users need this. The 6-piece endgames would be
nice, but I think you said there is 500 GB of endgame tables now and
it will be 1 TB by the time all the 6-piece ones are done. That needs
some serious disk space too!
64-bits do have thier place, there is no doubt about that, but just
for a minoriry of users. I wonder how long before we see general
purpose 128 BIT CPUs ???
Dr. David Kirkby.
Anders Carlsson
> I agree Sun have lost their way on performance. They really
> don't cut the mustard any more for CPU intensive tasks.
(goes more off-topic)
Sun has announced low-end AMD based workstations. As AMD's 32-bit
line is about to be phased out, one wonders if these machines will
feature Athlon 64/FX or Opteron and how Sun then will justify their
own architecture as high-end? Besides, rumours about Apple + AMD
and Apple + Sun have also circulated in the press.
Robert Hyatt
I bet it won't be _that_ long. I still remember the old "who needs
the 16 bit 80286?" A few years later "we have good 16 bit machines, who
needs the 80386?" Today it is "who needs the opteron, Itanium, etc?"
Tomorrow ... :)
Robert Hyatt
> Dr. David Kirkby writes:
>> I agree Sun have lost their way on performance. They really
>> don't cut the mustard any more for CPU intensive tasks.
> (goes more off-topic)
> Sun has announced low-end AMD based workstations. As AMD's 32-bit
> line is about to be phased out, one wonders if these machines will
> feature Athlon 64/FX or Opteron and how Sun then will justify their
> own architecture as high-end? Besides, rumours about Apple + AMD
> and Apple + Sun have also circulated in the press.
There have also been _plenty_ of rumors that "sparc is dead, long live
X86 and X86-64" in the Sun product line. :)
> --
> Anders Carlsson
> Ye wonder, she's thirteen beyond an invisible carefully preserved leather
> mouse. Sunday dungeons promising horseback cause loud guessed scissors.
--