log in

i686 instead of x86_64: why?


Advanced search

Message boards : Sixtrack Application : i686 instead of x86_64: why?

1 · 2 · Next
Author Message
Luigi R.
Send message
Joined: 7 Feb 14
Posts: 27
Credit: 1,529,701
RAC: 13
Message 28653 - Posted: 24 Jan 2017, 22:07:57 UTC
Last modified: 24 Jan 2017, 22:54:51 UTC

My i7-4770k is running SixTrack v451.07 i686-pc-linux-gnu (sse2). Should not it be faster to run SixTrack v451.07 x86_64-pc-linux-gnu (sse2)?

Application details for host 10408772:
SixTrack 451.07 i686-pc-linux-gnu (sse2): 41.41 GFLOPS
SixTrack 451.07 x86_64-pc-linux-gnu (sse2): 7.81 GFLOPS

I see all top computers are running 64bit version.
My i7 looks slower using 32bit version, but it still gets it cause of its average processing rate. I don't know.

Profile Ray Murray
Volunteer moderator
Avatar
Send message
Joined: 29 Sep 04
Posts: 146
Credit: 5,068,673
RAC: 3,664
Message 28673 - Posted: 26 Jan 2017, 13:53:22 UTC - in response to Message 28653.
Last modified: 26 Jan 2017, 14:00:47 UTC

Amongst the tasks to be sent out there will be a number of configurations, eg sse, sse2, pni etc. so that as many as possible, even lower spec machines, will be able to contribute. If there aren't any tasks of the flavour that your machines can run the fastest, they will get another flavour that they are (more than) capable of running so sometimes they will get these kind of tasks rather than not getting any at all.

kyrsjo
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 23 Jan 17
Posts: 29
Credit: 128,788
RAC: 252
Message 28793 - Posted: 6 Feb 2017, 10:00:53 UTC
Last modified: 6 Feb 2017, 10:01:42 UTC

AFAIK the 64-bit binaries are actually 32-bit, just renamed. Take a look with "file" command:

sixtrack_lin32_4517_pni.linux: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.18, BuildID[sha1]=b42e105d3abfa5c510f49b725ce1647140763030, not stripped

sixtrack_lin32_4517_sse2.linux: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.18, BuildID[sha1]=f421c2e66bd497329337d2e2d49f409753df4e51, not stripped

sixtrack_lin64_4517_pni.linux: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.18, BuildID[sha1]=b42e105d3abfa5c510f49b725ce1647140763030, not stripped

sixtrack_lin64_4517_sse2.linux: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.18, BuildID[sha1]=f421c2e66bd497329337d2e2d49f409753df4e51, not stripped

Profile Joe's Collider
Send message
Joined: 13 May 12
Posts: 1
Credit: 41,642
RAC: 5
Message 28803 - Posted: 6 Feb 2017, 22:03:32 UTC

Many BOINC projects make most of their use with the floating point processor(s). You could think of this as a separate processor (like in the days of the 386CPU & 387FPU). Or in today's world, making use of the hundreds of FPUs in graphics cards to crunch in 30 seconds, something that would be hours on a generic CPU.

The rest of the program could be thought of as file handling and moving the results into/out_of files - although it may make a larger portion of the program, very little time is expected to be used there - I would not expect large speed gains comparing 32 and 64 bit code.

...I've got a low score, but I'm just contributing (otherwise) wasted CPU cycles to science :-)

Eric Mcintosh
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 12 Jul 11
Posts: 843
Credit: 1,446,391
RAC: 115
Message 28807 - Posted: 7 Feb 2017, 10:39:51 UTC

Well I must admit we just use 32-bit even on 64-bit systems. This is just to try
and keep the number of executables and the amount of testing to a minimum.
I suppose we also save a very little memory. Remember my priorities are
Reliability, Functionality and Performance in that order, even if I get it wrong
sometimes ! :-)
We are coming shortly with AVX, SSE2, and generic versions for all platforms
(but 64-bit for Macs). I'll rerun timing tests after this big task is complete.
Clearly SSE2/AVX are big performance improvements. More news whenever. Eric.
____________

Desti
Send message
Joined: 16 Jul 05
Posts: 84
Credit: 1,053,743
RAC: 308
Message 30828 - Posted: 18 Jun 2017, 15:45:36 UTC - in response to Message 28807.

Well I must admit we just use 32-bit even on 64-bit systems. This is just to try
and keep the number of executables and the amount of testing to a minimum.
I suppose we also save a very little memory. Remember my priorities are
Reliability, Functionality and Performance in that order, even if I get it wrong
sometimes ! :-)
We are coming shortly with AVX, SSE2, and generic versions for all platforms
(but 64-bit for Macs). I'll rerun timing tests after this big task is complete.
Clearly SSE2/AVX are big performance improvements. More news whenever. Eric.



Isn't it about time to just drop 32 bit support? 32 bit only processors are more then 10 years old and their number and performance must be close to irrelevant in the total crunching pool.
____________
Linux Users Everywhere @ BOINC
[url=http://lhcathome.cern.ch/team_display.php?teamid=717]

Harri Liljeroos
Avatar
Send message
Joined: 28 Sep 04
Posts: 205
Credit: 6,170,432
RAC: 2,898
Message 30829 - Posted: 18 Jun 2017, 17:35:46 UTC - in response to Message 30828.

Well I must admit we just use 32-bit even on 64-bit systems. This is just to try
and keep the number of executables and the amount of testing to a minimum.
I suppose we also save a very little memory. Remember my priorities are
Reliability, Functionality and Performance in that order, even if I get it wrong
sometimes ! :-)
We are coming shortly with AVX, SSE2, and generic versions for all platforms
(but 64-bit for Macs). I'll rerun timing tests after this big task is complete.
Clearly SSE2/AVX are big performance improvements. More news whenever. Eric.



Isn't it about time to just drop 32 bit support? 32 bit only processors are more then 10 years old and their number and performance must be close to irrelevant in the total crunching pool.


There are still a lot of 64 bit CPUs that are running 32 bit operating systems.
____________

Eric Mcintosh
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 12 Jul 11
Posts: 843
Credit: 1,446,391
RAC: 115
Message 30836 - Posted: 19 Jun 2017, 4:35:49 UTC - in response to Message 30829.

Thanks Harri. I believe our strength is in numbers. Why throw away if you
can still do something useful. "Many a mickle maks a muckle" :-) Eric.
(I will be running tests soon to re-compare 32-bit/64-bit performance.)
____________

Toby Broom
Volunteer moderator
Send message
Joined: 27 Sep 08
Posts: 375
Credit: 88,313,439
RAC: 172,925
Message 30887 - Posted: 19 Jun 2017, 21:10:28 UTC

If x64 doesn't make an improvement then there is little motivation to make the change.

In regards to retirement of older executionn paths, I would assume that it could be tested or even queried from the db to understand the impacts to assess impact of retirement.

Are these stringes reported back to the server?

Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 fma cx16 sse4_1 sse4_2 movebe popcnt aes f16c rdrandsyscall nx lm avx avx2 vmx smx tm2 dca pbe fsgsbase bmi1

Eric Mcintosh
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 12 Jul 11
Posts: 843
Credit: 1,446,391
RAC: 115
Message 30888 - Posted: 19 Jun 2017, 21:40:37 UTC - in response to Message 30887.

I don't think they are reported, I don't see them. In the future we should look
at /proc/cpuinfo on Linux, not sure for Windows. Eric.
(But call system() isn't portable to Windows if I remember well. )
____________

Toby Broom
Volunteer moderator
Send message
Joined: 27 Sep 08
Posts: 375
Credit: 88,313,439
RAC: 172,925
Message 30892 - Posted: 20 Jun 2017, 6:41:05 UTC

This list comes from boinc, I assume it's exposed programmatically or reading the log files. You could the store in database for metrics on what the command set levels are.

After that it's a decision on what level of cpu you wish to go down to

computezrmle
Send message
Joined: 15 Jun 08
Posts: 347
Credit: 3,494,852
RAC: 1,536
Message 30893 - Posted: 20 Jun 2017, 7:29:43 UTC

Processor features

...Are these stringes reported back to the server?...

...I don't think they are reported...


At least on linux the processor features are written to the scheduler request file and then send to the project server:

<host_info> . . . <p_vendor>GenuineIntel</p_vendor> <p_model>Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz [Family 6 Model 58 Stepping 9]</p_model> <p_features>... sse sse2 ... pni ... ssse3 ... sse4_1 sse4_2 ... avx ...</p_features> . . . </host_info>



Also included in the scheduler request file:

<platform_name>x86_64-pc-linux-gnu</platform_name> <alt_platform> <name>i686-pc-linux-gnu</name> </alt_platform>


With this information the server is able to decide whith type of (CPU-)application can be send to the client.

Toby Broom
Volunteer moderator
Send message
Joined: 27 Sep 08
Posts: 375
Credit: 88,313,439
RAC: 172,925
Message 30912 - Posted: 20 Jun 2017, 18:29:53 UTC - in response to Message 30893.

I see the same one windows in the xml file.

In theory it would be possiable to mine the data for trends.

Eric Mcintosh
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 12 Jul 11
Posts: 843
Credit: 1,446,391
RAC: 115
Message 30913 - Posted: 21 Jun 2017, 7:56:34 UTC - in response to Message 30912.

Sorry, Yes, they must be reported as they are not in the Database.
I just need to find the appropriate log messages and I can try
some mining. (I can see Pentium 3, 4 Xeon, etc etc.) Eric.
____________

Desti
Send message
Joined: 16 Jul 05
Posts: 84
Credit: 1,053,743
RAC: 308
Message 30994 - Posted: 23 Jun 2017, 23:48:52 UTC - in response to Message 30836.

Thanks Harri. I believe our strength is in numbers. Why throw away if you
can still do something useful. "Many a mickle maks a muckle" :-) Eric.
(I will be running tests soon to re-compare 32-bit/64-bit performance.)



If you don't optimise for 64 bit and the modern extensions they have, because you want to have the backward compatibility for deprecated hardware, you will waste much more pool performance, than what you would lose by kicking the old systems out.
____________
Linux Users Everywhere @ BOINC
[url=http://lhcathome.cern.ch/team_display.php?teamid=717]

Eric Mcintosh
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 12 Jul 11
Posts: 843
Credit: 1,446,391
RAC: 115
Message 30996 - Posted: 24 Jun 2017, 0:14:29 UTC - in response to Message 30994.

OK, I will try. I was thinking of having native 64-bit anyway.
I'll report the results. Eric.
____________

gyllic
Send message
Joined: 9 Dec 14
Posts: 93
Credit: 1,084,130
RAC: 4,748
Message 32412 - Posted: 13 Sep 2017, 8:36:06 UTC

Have you made any changes regarding this topic?
Just wondering because some PCs still get 32bit apps on 64bit CPUs (and OSs).
So is this still normal behaviour or is this some kind of a bug?

Alessio Mereghetti
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 29 Feb 16
Posts: 34
Credit: 418,281
RAC: 134
Message 32429 - Posted: 15 Sep 2017, 6:52:25 UTC - in response to Message 32412.

We are still investigating this aspect, together with the avx/sse2 fractions.
For the moment we see that ~60% (~75%) of results produced in the last 24h with Win (Lin) exes are from the 64bit version. These figures are a bit floating, but for Linux the fraction of results generated with 64bit version seems to be growing...

computezrmle
Send message
Joined: 15 Jun 08
Posts: 347
Credit: 3,494,852
RAC: 1,536
Message 32430 - Posted: 15 Sep 2017, 7:34:12 UTC - in response to Message 32429.

... for Linux the fraction of results generated with 64bit version seems to be growing...

The BOINC client can be configured not to ask for alternative platform apps via <no_alt_platform>1</no_alt_platform> in the cc_config.xml (followed by "reload config files").
See: https://boinc.berkeley.edu/wiki/Client_configuration
Disadvantage: This affects all attached projects on this host.

Nonetheless this is not a guarantee that the host runs the fastest possible app as under distinct circumstances a 32 bit app on a 64 bit host may be as fast (or even faster) as a native 64 bit app.
In addition it does not solve the SSEx/AVX issue.

As I mentioned here a test with well known WUs (repeated after some time or a distinct #WUs) may be the only way to get reliable performance data.
In the long term the project would benefit from such a test as most of the hosts would run the app they perform best with.

maeax
Send message
Joined: 2 May 07
Posts: 229
Credit: 11,965,588
RAC: 14,359
Message 32431 - Posted: 15 Sep 2017, 7:50:37 UTC

What when the Volunteer had installed the 32-bit Boinc on a 64-bit PC?

1 · 2 · Next

Message boards : Sixtrack Application : i686 instead of x86_64: why?