Einstein@Home for 64-bit Linux on AMD Athlon 64 X2

Jure Repinc (JLP)
Jure Repinc (JLP)
Joined: 22 Jan 05
Posts: 13
Credit: 7393020
RAC: 0
Topic 191637

Hi,

I have ordered Athlon 64 X2 4200+ in the past week which should arrive this week. Before I get it I would like to be prepared to get the most out of it for E@H.

Currently I'm running Athlon 64 3000+ so I would like to know what I need to configure/change in Linux to take full adventage of Athlon 64 X2 with two cores. I would also like to know if there is anything I need to change in BOINC so that it uses both cores to work on work units.

Thanks in advance for all the help.

RenaudKener
RenaudKener
Joined: 11 Jun 06
Posts: 91
Credit: 5614714
RAC: 0

Einstein@Home for 64-bit Linux on AMD Athlon 64 X2

Quote:

Hi,

I have ordered Athlon 64 X2 4200+ in the past week which should arrive this week. Before I get it I would like to be prepared to get the most out of it for E@H.

Currently I'm running Athlon 64 3000+ so I would like to know what I need to configure/change in Linux to take full adventage of Athlon 64 X2 with two cores. I would also like to know if there is anything I need to change in BOINC so that it uses both cores to work on work units.

Thanks in advance for all the help.

Hello.
The answer depends a lot of the linux's distribution you'll install on your new computer.
Would you mind tell us wich one ?

Generally speaking, any good distribution will recognize your 64 bits architecture. Be sure to install a kernel SMP-compliant if the default isn't it.
Later, if you feel confident enough, you may compile your own custom-made kernel from sources. This last one will have "everything you need" but "only what you need" and won't be encumbered with features YOU do not employ.
BOINC will detect your setting automatically - 2 CPU will show in your detail's sheet.
I wish you good luck and fun with your brand new computer.

"Entia non sunt multiplicandam praeter necessitatem"
(OKHAM)

Michael Karlinsky
Michael Karlinsky
Joined: 22 Jan 05
Posts: 888
Credit: 23502182
RAC: 0

RE: Generally speaking,

Message 43266 in response to message 43265

Quote:

Generally speaking, any good distribution will recognize your 64 bits architecture. Be sure to install a kernel SMP-compliant if the default isn't it.

And therein lies the problem. There is no 64 bit Einstein application. So you need to install at least the 32 bit libraries. If you do not take advantage of 64 bit features, like more that 4 GB RAM, I suggest you install the 32 bit OS. And don't forget to install the SMP kernel!

Michael

PS: Welcome to Team 'Linux Users Everywhere', Jure Repinc and RenaudKener.

Jure Repinc (JLP)
Jure Repinc (JLP)
Joined: 22 Jan 05
Posts: 13
Credit: 7393020
RAC: 0

RenaudKener: Linux (Gentoo)

RenaudKener:
Linux (Gentoo) is already installed on the computer. So I only needed to know what to change when I change the CPU from the current single core to dual-core. So If I understand it correctly I only need to recompile the kernel with SMP enabled and this should be it? E@H will then automatically use both cores?

Michael Karlinsky:
Yeah it is quite disappointing that there is still no 64-bit E@H client optimised for AMD64. Not even beta one. And after all those years of the architecture being out. Ah well guess we will have to wait a little bit longer and until then just use the 32-bit client.
Oh and thanks for the welcome.

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1364
Credit: 3562358667
RAC: 1580

there is NO, Zero, Zip, Nada

there is NO, Zero, Zip, Nada benefit to a 64 bit einstien app, and one penalty from using it. A 64 bit cpu does two things differently: Tt provides 64 bit integer support, this is useless for einstien and most other boinc projects because they use floating point arithmatic instead. It also provides 64bit memory addressing. This is useless unless you need more than 4gig of memory. Einstien doesn't, and afaik the only project that might need it it reasonable nearterm (next few years) future is CPDN. For apps that don't need 64bit memory addressing using it slows them down since all the memory addresses (used for the if/elses, loops, function calls, etc) are now twice as big and require twice as much cache to store, and twice as much memory bandwidth to copy from the cache to main memory (and vice versa).

RenaudKener
RenaudKener
Joined: 11 Jun 06
Posts: 91
Credit: 5614714
RAC: 0

Good afternoon. Michael

Good afternoon.
Michael Karlinsky, thanks for the welcoming, it's nice of you.
I've installed SuSE 10.0 on my athlon64 with 32bits libraries AND 64 bits libraries, mostly
in /lib and /usr/lib for 32 bits
and /lib64 /usr/lib/64 for 64 bits version.

DanNeely is true about memory addressing issue, I quote him:
"For apps that don't need 64bit memory addressing using it slows them down since all the memory addresses (used for the if/elses, loops, function calls, etc) are now twice as big and require twice as much cache to store, and twice as much memory bandwidth to copy from the cache to main memory (and vice versa)."
Yes, could be a penalty... However !
- Athlon64 architecture is 64 and 32 bits capable natively, no 32 bit emulation.
- As far as I know ( and I may be wrong ! ) you can mix differents modes of addressing IF your executable lies in a LESS THAN 4 GB memory "segment".

From that, I infere (and still can be wrong :-) ) that a smart compiler like GCC 4.1 is able to optimize jumps in using shorts ones instead of longs ones. So, no bandwidth penalty.

I haven't downloaded the source code to study it ! Shame on me ! Lack of time, job and familly are heavily taxing my hacking time :-) (<= I'm joking ! ) Besides, I haven't done fine-tunig assembly language since 20 years ago - I began programming in year 1981, I'm kinda dinosaur.

Well, I am sure somebody did compile the source code in 64 bit mode and linked it with 64 bits libraries, with a thrice compiled gcc 4 to erase any trace of 32 code.
I'd be very interested to hear about - especially if there were problems and/or impossibilities to optimize for 64 bit AMD architecture.
I'd try it myself if my beloved wife were willing to spend some weeks with a Geek acting in life like a zombie ;-) Not before november, I'm afraid.

That's said, BOINC wants to keep the differents version of code as close as possible, and 32 bits machine are so far the majority yet. Maybe that'll change soon, with AMD dramatically dropping prices and the new dual core 2 Intels hitting the market.
Wait and see said Lord Nelson :-)

"Entia non sunt multiplicandam praeter necessitatem"
(OKHAM)

Metod, S56RKO
Metod, S56RKO
Joined: 11 Feb 05
Posts: 135
Credit: 808390799
RAC: 65848

RE: Well, I am sure

Message 43270 in response to message 43269

Quote:
Well, I am sure somebody did compile the source code in 64 bit mode and linked it with 64 bits libraries, with a thrice compiled gcc 4 to erase any trace of 32 code.
I'd be very interested to hear about - especially if there were problems and/or impossibilities to optimize for 64 bit AMD architecture.
I'd try it myself if my beloved wife were willing to spend some weeks with a Geek acting in life like a zombie ;-) Not before november, I'm afraid.

I did compile BOINC for AMD64 natively. My box runs AMD64 port of Debian Etch, so by default no 32 bits there. The binary is fine, however:

  • * benchmark figures (which almost don't matter anymore) are quite similar to those of self-compiled 32-bit version
    * BOINC CC doesn't take much of CPU time anyhow - science app does (Einstein in our case)
    * if you configure/compile BOINC without any twisting, it'll report architecture as linux-amd64 ... which means you're forced to use

anonymous platform tweaks
All in all, it's just not worth it.

Metod ...

RenaudKener
RenaudKener
Joined: 11 Jun 06
Posts: 91
Credit: 5614714
RAC: 0

Many thanks for the

Message 43271 in response to message 43270

Many thanks for the information :-)

Quote:
Quote:
Well, I am sure somebody did compile the source code in 64 bit mode and linked it with 64 bits libraries, with a thrice compiled gcc 4 to erase any trace of 32 code.
I'd be very interested to hear about - especially if there were problems and/or impossibilities to optimize for 64 bit AMD architecture.
I'd try it myself if my beloved wife were willing to spend some weeks with a Geek acting in life like a zombie ;-) Not before november, I'm afraid.

I did compile BOINC for AMD64 natively. My box runs AMD64 port of Debian Etch, so by default no 32 bits there. The binary is fine, however:

  • * benchmark figures (which almost don't matter anymore) are quite similar to those of self-compiled 32-bit version
    * BOINC CC doesn't take much of CPU time anyhow - science app does (Einstein in our case)
    * if you configure/compile BOINC without any twisting, it'll report architecture as linux-amd64 ... which means you're forced to use
anonymous platform tweaks
All in all, it's just not worth it.


"Entia non sunt multiplicandam praeter necessitatem"
(OKHAM)

ebahapo
Joined: 22 Jan 05
Posts: 47
Credit: 755276
RAC: 0

64-bit applications can

Message 43272 in response to message 43268

64-bit applications can benefit from more registers and better calling conventions. Typically, 64-bit applications have smaller code-size and are faster because of fewer register spills. On some OS, optimized math routines also improve the performance over legacy x87 code.

ebahapo
Joined: 22 Jan 05
Posts: 47
Credit: 755276
RAC: 0

So far, two projects have

So far, two projects have added support for x86-64: SETI sends the x86 application and SIMAP a true x86-64 application. Would you consider supporting x86_64-pc-linux-gnu or x86_64-unknown-linux-gnu similarly?

Metod, S56RKO
Metod, S56RKO
Joined: 11 Feb 05
Posts: 135
Credit: 808390799
RAC: 65848

RE: 64-bit applications can

Message 43274 in response to message 43272

Quote:
64-bit applications can benefit from more registers and better calling conventions. Typically, 64-bit applications have smaller code-size and are faster because of fewer register spills. On some OS, optimized math routines also improve the performance over legacy x87 code.


This has been discused gazillion times already. Most of at least somehow optimized (32-bit) apps already use any kind of vector maths (SSE, SSE2, 3Dnow!, MMX) so 64-bit version won't bring any benefit here. Additional number of registers would bring some gain if the science apps would be more general apps. Longer registers would bring some gain if app did a lot of long integer (64 bit) arithmetics. As most of science apps tend to be FPU (or SSE if you want) intensive, gain of useing additional registers (to avoid too many register to memory transfers) is neglectible.

If my memory serves me correctly, lads over at SETI found out that there's no difference in speed between 32 and 64 bit app if same set of compiler flags used. Some even reported that 64-bit app seems marginally slower. Which makes sense: in certain circumstances code is actually larger as you need to use 64-bit address space. In addition to that you need to push/pop a bit more data to stack and there are other little tidbits.

Face it, with current generation of AMD64-class processors, there's no big advantage to use 64 bit programmes unless a particular app needs to use more than 2 Gigabytes of memory. There's a lot more sense in running 64-bit OS though.
Please note that running 32-bit apps on AMD64 platform does not mean running them in any kind of emulator which would bring additional overhead and thusly a slow-down. It is somehow similar to ECOFF support in linux/alpha, which enables you to (natively) run OSF1 (Digital Unix) binaries under Linux - it nearly always meant getting considerable speedup comapred to running native Linux binaries as there was no emulation - just ability to run slightly differently formed executables and shared libraries.

Remark: above I'm referring to AMD64 platform. With that I'm referring both to 64-bit AMD processors as well as Intel processors with EM64T extensions.

Metod ...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.