upcoming core changes (bigadv will switch from A3 to A5)

[kasson]

Just a heads-up: we are planning to migrate bigadv from running on Core A3 to running on Core A5 very shortly. Core A5 utilizes the same codebase as A3, but pegged to specific version snapshots. We have 64-bit Linux, Win32, and 64-bit OS/X versions of the core in testing; the initial release will likely be Win32 & Linux.

The new core will require a client upgrade; A5 will require version 6.34 or later. The Linux and Win32 versions of the 6.34 client will be released to the public very shortly. If you are running bigadv work units, please upgrade your clients. That will ease the transition as we start turning Core A5 bigadv projects on and turning Core A3 bigadv projects off.

****added*****
Visit the download page:
http://folding.stanford.edu/English/DownloadWinOther
to download the 6.34 clients

Thanks and happy folding!

[Nathan_P]

any news of a 64bit windows client or is that a v7 thing?

[topodisc]

Does that mean Win7 64-bit (core A3) will no longer be getting bigadv work units, until core A5 is available?

[7im]

any news of a 64bit windows client or is that a v7 thing?

There is no advantage to a 64 bit client. There may be an advantage to a 64 bit fahcore, but only when they need to start using more than 2 GB of memory. Using 2 GB+ of memory would not be related to using a particular client version.

[7im]

Does that mean Win7 64-bit (core A3) will no longer be getting bigadv work units, until core A5 is available?

No. He said migrate, as in transition. Finish current A3 projects, and start new A5 projects soon, with overlap. The fahcore your client uses will depend on the work unit your client gets.

[topodisc]

any news of a 64bit windows client or is that a v7 thing?

There is no advantage to a 64 bit client. There may be an advantage to a 64 bit fahcore, but only when they need to start using more than 2 GB of memory. Using 2 GB+ of memory would not be related to using a particular client version.

That may be the case for F@H, but I don't think many people will install a 32-bit OS just for folding. These days 64-bit is becoming as ubiquitous as 32-bit.

[7im]

What do you mean about having to install a 32 bit OS? 32 bit apps runs just fine on 64 bit systems.

Or is there some 32 bit prejudice that I am not aware of?

[kasson]

We don't currently have 64-bit A3 Windows cores in release; 64-bit versions of windows run the 32-bit version. This may change in the future, but the initial release of A5 will use the same model.

The bigadv changeover will be relatively rapid; we highly encourage donors who wish to run bigadv to upgrade their clients to 6.34 or later within the first few days of public release. We do not normally perform rapid switchovers for public-release clients, but bigadv is more of a "power user" configuration. After the switchover, pre-6.34 clients set to bigadv will roll over to normal A3 work units (and thus won't be spinning their wheels idly). We also have a number of non-bigadv A3 projects ready for public release that cannot go public until bigadv migrates for technical reasons.

[topodisc]

What do you mean about having to install a 32 bit OS? 32 bit apps runs just fine on 64 bit systems.

Or is there some 32 bit prejudice that I am not aware of?

Nah, I just wasn't thinking.

[kasson]

The 6.34 binaries are now posted on the high-performance download page. We have a bit of cosmetic clean-up to do, but visit:
http://folding.stanford.edu/English/DownloadWinOther

to download the binaries. They can be dropped into a working FAH installation; it's always safest to update between work units, although testers have successfully performed this update mid-work-unit.

[MIBW]

Great news guys, looking forward to it. Hopefully this new core will address NUMA related issues.

snip. There may be an advantage to a 64 bit fahcore, but only when they need to start using more than 2 GB of memory. snip

There will be advantages in that we will be able to use more than about 60 cores. Plus other performance improvements.

[7im]

Gromacs is currently the limiting factor for using 32+ cores, not the OS or bit version. Not really a concern just yet. They can update to 64 bit when they update the fahcore to use more than 32 cores. Gromacs may be able to run with more than 32 now, but performance really tapers off.

To what other improvements do you refer?

[kasson]

Gromacs is currently the limiting factor for using 32+ cores, not the OS or bit version. Not really a concern just yet. They can update to 64 bit when they update the fahcore to use more than 32 cores. Gromacs may be able to run with more than 32 now, but performance really tapers off.

Fortunately, Gromacs is not the limiting factor. The limiting factors are the system being simulated, the OS/bit version, and the hardware. The systems we're running on bigadv scale to 1024 cores (on a Cray) with ~75% efficiency. We've had good success increasing this to 1536 cores on some newer architectures (XE). It looks really pretty.

In terms of translating that to single-node performance with many cores on "consumer" setups, there are a number of issues; address space is one of them (but not the only one).

[7im]

I stand corrected on the gating factors. Windows is always the problem.

Still, duplicating the work load by building, testing, and supporting 2 fahcore versions (32 bit and 64 bit) is not helpful unless there is a significant reason to go 64 bit. My point is that 64 bit isn't going to be released just because it's cool to have all 64 bits apps on a person's shiny new 64 bit machine.

Still waiting to hear what other improvements 64 bit would bring to the table...

And just to shoo the big cray elephant out of the room, what's the PPD on that 1024 node system?

[MIBW]

Gromacs is currently the limiting factor for using 32+ cores, not the OS or bit version. Not really a concern just yet. They can update to 64 bit when they update the fahcore to use more than 32 cores. Gromacs may be able to run with more than 32 now, but performance really tapers off.

The folks running 48 cores note that scaling performance is virtually perfect compared to 24 cores, so whatever the taper point is, it starts above 48 cores.