AMD Compile?

Message boards : Number crunching : AMD Compile?
Message board moderation

To post messages, you must log in.

AuthorMessage
Yavanius
Volunteer tester
Avatar

Send message
Joined: 8 Jul 99
Posts: 50
Credit: 249,309
RAC: 0
Antarctica
Message 13112 - Posted: 28 Jul 2004, 14:56:15 UTC

I've been looking around and was surprised to see there had been no AMD platform compiles and was wondering why this was?

Did Berkeley tell a white lie and put in AMD optimizations? Did someone try and not find a signficant difference? Has no one thought to try (I would have though the AMD groups would have been all over this day one)?

Thanks,

David
SETI Tech Desk
http://egroups.com/group/SETI_techdesk
ID: 13112 · Report as offensive
Profile Christopher Hauber
Avatar

Send message
Joined: 10 Feb 01
Posts: 196
Credit: 71,611
RAC: 0
United States
Message 13113 - Posted: 28 Jul 2004, 15:03:19 UTC - in response to Message 13112.  

On the original SETI site, somewhere I saw something where they mentioned compiling with an AMD flag or something to add the optimizations for it and there was no difference so they didn't keep up with it. I don't remember where it was exactly -- it was a long time ago. It might have been the download page (the one that has the most compilations).

Chris

> I've been looking around and was surprised to see there had been no AMD
> platform compiles and was wondering why this was?
>
> Did Berkeley tell a white lie and put in AMD optimizations? Did someone try
> and not find a signficant difference? Has no one thought to try (I would have
> though the AMD groups would have been all over this day one)?
>
> Thanks,
>
> David
> SETI Tech Desk
> http://egroups.com/group/SETI_techdesk
>
ID: 13113 · Report as offensive
Yavanius
Volunteer tester
Avatar

Send message
Joined: 8 Jul 99
Posts: 50
Credit: 249,309
RAC: 0
Antarctica
Message 14175 - Posted: 6 Aug 2004, 0:48:57 UTC

I remember that too for classic. But I'm wondering with the 3D Graphics if they threw it in? Also, AMD chips have evolved quite a bit from those days too. I'm curious to know if the raw floating point power of the Athlon line is more than suffice to not need the optimizations or not?

I'd be curious to see someone try a custom compile and compare it to the default compile and post the results.

~David
ID: 14175 · Report as offensive
Profile KWSN - MajorKong
Volunteer tester
Avatar

Send message
Joined: 5 Jan 00
Posts: 2892
Credit: 1,499,890
RAC: 0
United States
Message 14566 - Posted: 7 Aug 2004, 15:21:37 UTC - in response to Message 13113.  

> On the original SETI site, somewhere I saw something where they mentioned
> compiling with an AMD flag or something to add the optimizations for it and
> there was no difference so they didn't keep up with it. I don't remember where
> it was exactly -- it was a long time ago. It might have been the download page
> (the one that has the most compilations).
>
> Chris
>


As I recall from 'back in the day', the Staff at Berkeley decided against CPU-specific optimizations (3dnow, SSE, altivec, etc.) because they wanted to keep the 'science source-code' the same across all platforms (Berkeley's story). Using, for instance 3d-now (from AMD) would have required a re-write of the 'science' source-code. AMD (and others) *produced* 'optimized compiles' of S@H-Classic, but Berkeley refused to use them. At the time, many of us were of the opinion that another reason Berkeley refused to use them was that they were being almost constantly overloaded (bandwidth into the project, server capacity, etc.), and that using optimized compiles would only make things worse (faster clients = more traffic and server load). This opinion got re-inforced several times as Berkely introduced additional 'science' into the client (which had the effect of slowing it down). In the V3.x client series, they DID greatly improve the FFT routines' speed, but also loaded down the client with extra scans, producing no net gain in speed but instead slowed it down.

On the 'intel-compatable' CPUs, they used either one or two different 'optimization' levels, depending on the OS (some got a few 'minor' versions due to various incompatabilities, but the mainstream Windoze and Linux got one or two optimization levels, respectively). Windows got one level, the 'i386' level. It used a 'blended Pentium' optimization scheme, running on i386s but running best on pentium-class CPUS. Additionally, Linux got an 'i686' opt. level, which would supposedly only run on Pentium Pros, Pentium IIs, and better). As the project went along, the number of 'variants' was reduced (as 'porters' dropped out). During the v3.x cutover, the Berkeley staff had stated their wishes that the number of 'ports' be reduced for reasons of efficiency. By this time, 'processor specific optimized' versions would not have accepted for use anyway for this reason.

Since that 'days of long ago' era, compilers have become MUCH more efficient at optimization, and the various CPUs have become MUCH more powerful. It might be worthwhile to produce versions that are optimized for various processors now. For instance with the current GCC compilers on Linux, perhaps using the 'march=AthlonXP' flag might produce code that runs a tad faster on AthlonXPs. However, unless the science code has provisions in it to use things like 3dNow or SSE(2), I doubt the science code would run very much faster. One place where it MIGHT help is in the graphics display (for you graphics junkies -- less system load due to graphics generation = more CPU cycles available for the science code... but I can't test that because the 'pretty pictures' are, for now, windoze specific).

One advantage that BOINC and BOINC/S@H has over S@H-Classic is that the source code is available, and one can try a custom compile oneself, if one so desires. I've done it a couple of times on linux (GCC for linux is free, Visual C++ for windoze ain't), but never did any timeing tests between the Berkeley version and mine. Maybe I will try it again and do the tests during the V4.x cutover on BOINC (when that happens, might be a while).
------------
KWSN-MajorKong
KWSN Forum Admin (retired)
http://www.kwsnforum.com

BOINC Beta tester

ID: 14566 · Report as offensive
Profile JigPu
Avatar

Send message
Joined: 16 Feb 00
Posts: 99
Credit: 2,513,738
RAC: 0
Message 14680 - Posted: 8 Aug 2004, 3:25:51 UTC - in response to Message 14566.  
Last modified: 8 Aug 2004, 3:26:11 UTC

> One place where it MIGHT help is in the graphics display (for you
> graphics junkies -- less system load due to graphics generation = more CPU
> cycles available for the science code... but I can't test that because the
> 'pretty pictures' are, for now, windoze specific).

I doubt the optimizations would help the graphics display much, since it's written in OpenGL and so runs almost completely off of the GPU. Original SETI used CPU generated graphs, which explains the big speed difference between the CLC and GUI. Also, if you're concerned about GUI CPU usage now, you can restrict the CPU time spent on that task through the preferences. I have it set at 0.5% and it works fine, though I've tested down to 0.2% with no glitches.

Here's hoping for some optimized windows builds though :) Just can't convince the parents to run linux quite yet :D


_______________________________

ID: 14680 · Report as offensive

Message boards : Number crunching : AMD Compile?


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.