LHC@home

> Win32 operating systems. However I don't know if sixtrack currently uses SSE
> or if it could even benefit from using SSE instructions in the first place.

SSE could yield performance increase but it's disabled because it has seen to cause numeric differencies on different platforms. Sixtrack is extremely sensitive to numeric accuracy - for a certain double precision floating point operation, all platforms must give the same answer, in all the 80 bits, or the simulation may give very different end-results.

---

Markku Degerholm
LHC@home admin

> Sixtrack is extremely sensitive to numeric accuracy - for a certain double
> precision floating point operation, all platforms must give the same answer,
> in all the 80 bits, or the simulation may give very different end-results.

Explains a lot! Thanks Markku

---

> > Win32 operating systems. However I don't know if sixtrack currently uses
> SSE
> > or if it could even benefit from using SSE instructions in the first
> place.
>
> SSE could yield performance increase but it's disabled because it has seen to
> cause numeric differencies on different platforms. Sixtrack is extremely
> sensitive to numeric accuracy - for a certain double precision floating point
> operation, all platforms must give the same answer, in all the 80 bits, or the
> simulation may give very different end-results.
>
>
Thanks Markku. :-D

---

Markku,

Can I get you to change the link on the site to point to the Wiki instead of the old site?

Also, would you be interested in contributing to the Wiki as an LHC@Home advocate?

---

Hi All

Here are my thoughts on the subject.

I have an Intel 640 CPU on a ASUS PH3 Chassis

Not top notch but a nice ultra stable config.

I have tried both Win XP and Win XP 64Bit.

I fully understand the implication of 64bit computing its benefits and its disadvantages.

From a BOINC point of view. if a 64Bit Core client was available their would be a small benefit. Some projects might gain advantages if require large integer math ops.

But at the moment their is very little between the 2 OS's running BOINC if anything the 64Bit is running marginally slower.

However, the system as a whole seems more responsive with a 64Bit OS this is due most likly to 2 factors, 64Bit code for the OS and all drivers for hardware must be 64Bit.

If you have a pure 64Bit app you will definately benefit. Their is little benefit from running 32Bit apps under the 64Bit OS.

I needed to evaluate the potentual of the 64Bit OS as it is likly to become a part of product range in the near future. As we support everything we do. (Well almost everything) I had to get some hands-on experence.

I like my 64Bit setup. I can't fault it, but it might have been nicer if went just a tad faster.

---

<img border="0" src="http://boinc.mundayweb.com/one/stats.php?userID=2104" />

Ian,

Short response, I promise:

1) If the BOINC Manager went 64-bit there wouldn't be a substantial performance increase in the way BOINC/BOINC Manager handles multiple projects. In 198780 seconds of uptime BOINC consumed 61 seconds of that on my 32-bit system; another has 853920 secs uptime, 384 secs processing time. :)

2) LHC@Home's sixtrack application will not benefit from being a 64-bit native application because it already uses "80-bit" (if you will) data processing.

3) Other applications which run on BOINC/BOINC Manager may benefit from 64-bit integer instructions, but it depends on the type of data being processed. Obviously Integer and SSEx instructions stand to gain the most performance. FPU/MMX instructions gain nothing (hence #2).

4) BOINC-enabled applications do not make BOINC/BOINC Manager execute instructions for them. BOINC is a platform which allows multiple distributed applications to be ran with intelligent networking and scheduling. BOINC makes sixtrack, hadsm3, mfold and others run as independent programs, manages them, and communicates back to the host project when appropriate. BOINC in and of itself has nothing to do with how the apps run, what instructions they use or process data.

---

Hi

I did mention if the core client was 64Bit it would have a slight benefit.

If it has a great benefit - The programmer's need shooting. I would sincerely hope that the the project switching overhead is a very small % less than 1%.

If a new generation of the FPU unit on the CPU was developed you could expect a significant improvement. 80Bits is just a register size of the FPU. Loading the data into the register 2 operation (64Bit) and I am guessing here shall we say 60 clock cycles as opposed to 90 cycles 3 Load operations for (32Bit) gets a bit lost in 4000-5000 cycles the muliplication takes.

As for using the power for other functions yes they could benefit performance, but not the science.

I am not complaing I was just pointing out where benefits could be achieved. The statement is a general one and applies to all the the projects.

I didn't consider the non science parts of the project. These could benefit signifcantly, but have little value as far as the science is concerned.

I have no doubt that in the fulness of time we will see some projects taking advantage of 64Bit power.

I understand the basic function of the core client if it can switch projects faster access the disk faster comminicate faster their is more project processing time.

---

<img border="0" src="http://boinc.mundayweb.com/one/stats.php?userID=2104" />

> 80Bits is just a register size of the FPU. Loading
> the data into the register 2 operation (64Bit) and I am guessing here shall we
> say 60 clock cycles as opposed to 90 cycles 3 Load operations for (32Bit) gets
> a bit lost in 4000-5000 cycles the muliplication takes.

Why take multiplication out of the FPU? Use FPMul .. that way data in the FPU register isn't concantenated like it would be if it is transferred to a GPR..

Actually, unless specifically programmed for this, the FP number size is 32 bits for a single and 64 bits for a double ... the value is extended to 80 bit but converted back, usually with truncation to a 32 or 64 bit value. The 80 bits allows for greater dynamic range so, for example, a double * double does create an overflow.

Repeated operations using the available registers allows propagation internally of 80 bit values so the end result of a series is more accurate.

---