Message boards :
Sixtrack Application :
i686 instead of x86_64: why?
Message board moderation
Author | Message |
---|---|
Send message Joined: 7 Feb 14 Posts: 99 Credit: 5,180,005 RAC: 0 |
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. |
Send message Joined: 29 Sep 04 Posts: 281 Credit: 11,859,285 RAC: 1 |
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. |
Send message Joined: 23 Jan 17 Posts: 29 Credit: 375,570 RAC: 0 |
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 |
Send message Joined: 13 May 12 Posts: 2 Credit: 69,263 RAC: 0 |
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 :-) |
Send message Joined: 12 Jul 11 Posts: 857 Credit: 1,619,050 RAC: 0 |
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. |
Send message Joined: 16 Jul 05 Posts: 84 Credit: 1,875,851 RAC: 0 |
Well I must admit we just use 32-bit even on 64-bit systems. This is just to try 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] |
Send message Joined: 28 Sep 04 Posts: 674 Credit: 43,150,492 RAC: 15,942 |
Well I must admit we just use 32-bit even on 64-bit systems. This is just to try There are still a lot of 64 bit CPUs that are running 32 bit operating systems. |
Send message Joined: 12 Jul 11 Posts: 857 Credit: 1,619,050 RAC: 0 |
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.) |
Send message Joined: 27 Sep 08 Posts: 798 Credit: 644,727,872 RAC: 233,979 |
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 |
Send message Joined: 12 Jul 11 Posts: 857 Credit: 1,619,050 RAC: 0 |
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. ) |
Send message Joined: 27 Sep 08 Posts: 798 Credit: 644,727,872 RAC: 233,979 |
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 |
Send message Joined: 15 Jun 08 Posts: 2386 Credit: 222,926,275 RAC: 137,719 |
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. |
Send message Joined: 27 Sep 08 Posts: 798 Credit: 644,727,872 RAC: 233,979 |
I see the same one windows in the xml file. In theory it would be possiable to mine the data for trends. |
Send message Joined: 12 Jul 11 Posts: 857 Credit: 1,619,050 RAC: 0 |
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. |
Send message Joined: 16 Jul 05 Posts: 84 Credit: 1,875,851 RAC: 0 |
Thanks Harri. I believe our strength is in numbers. Why throw away if you 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] |
Send message Joined: 12 Jul 11 Posts: 857 Credit: 1,619,050 RAC: 0 |
OK, I will try. I was thinking of having native 64-bit anyway. I'll report the results. Eric. |
Send message Joined: 9 Dec 14 Posts: 202 Credit: 2,533,875 RAC: 0 |
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? |
Send message Joined: 29 Feb 16 Posts: 157 Credit: 2,659,975 RAC: 0 |
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... |
Send message Joined: 15 Jun 08 Posts: 2386 Credit: 222,926,275 RAC: 137,719 |
... 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. |
Send message Joined: 2 May 07 Posts: 2071 Credit: 156,095,661 RAC: 103,406 |
What when the Volunteer had installed the 32-bit Boinc on a 64-bit PC? |
©2024 CERN