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

To post messages, you must log in.

1 · 2 · Next

AuthorMessage
Luigi R.

Send message
Joined: 7 Feb 14
Posts: 27
Credit: 1,548,647
RAC: 229
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.
ID: 28653 · Report as offensive     Reply Quote
Profile Ray Murray
Volunteer moderator
Avatar

Send message
Joined: 29 Sep 04
Posts: 170
Credit: 6,025,761
RAC: 5,302
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.
ID: 28673 · Report as offensive     Reply Quote
kyrsjo
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 23 Jan 17
Posts: 29
Credit: 315,185
RAC: 1,045
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
ID: 28793 · Report as offensive     Reply Quote
Profile Joe's Collider

Send message
Joined: 13 May 12
Posts: 2
Credit: 61,013
RAC: 89
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 :-)
ID: 28803 · Report as offensive     Reply Quote
Eric Mcintosh
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 12 Jul 11
Posts: 843
Credit: 1,578,195
RAC: 665
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.
ID: 28807 · Report as offensive     Reply Quote
Desti

Send message
Joined: 16 Jul 05
Posts: 84
Credit: 1,567,735
RAC: 2,165
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]
ID: 30828 · Report as offensive     Reply Quote
Harri Liljeroos
Avatar

Send message
Joined: 28 Sep 04
Posts: 267
Credit: 8,937,205
RAC: 13,246
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.
ID: 30829 · Report as offensive     Reply Quote
Eric Mcintosh
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 12 Jul 11
Posts: 843
Credit: 1,578,195
RAC: 665
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.)
ID: 30836 · Report as offensive     Reply Quote
Toby Broom
Volunteer moderator

Send message
Joined: 27 Sep 08
Posts: 425
Credit: 118,205,949
RAC: 161,160
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
ID: 30887 · Report as offensive     Reply Quote
Eric Mcintosh
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 12 Jul 11
Posts: 843
Credit: 1,578,195
RAC: 665
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. )
ID: 30888 · Report as offensive     Reply Quote
Toby Broom
Volunteer moderator

Send message
Joined: 27 Sep 08
Posts: 425
Credit: 118,205,949
RAC: 161,160
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
ID: 30892 · Report as offensive     Reply Quote
computezrmle

Send message
Joined: 15 Jun 08
Posts: 604
Credit: 6,458,345
RAC: 15,791
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.
ID: 30893 · Report as offensive     Reply Quote
Toby Broom
Volunteer moderator

Send message
Joined: 27 Sep 08
Posts: 425
Credit: 118,205,949
RAC: 161,160
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.
ID: 30912 · Report as offensive     Reply Quote
Eric Mcintosh
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 12 Jul 11
Posts: 843
Credit: 1,578,195
RAC: 665
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.
ID: 30913 · Report as offensive     Reply Quote
Desti

Send message
Joined: 16 Jul 05
Posts: 84
Credit: 1,567,735
RAC: 2,165
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]
ID: 30994 · Report as offensive     Reply Quote
Eric Mcintosh
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 12 Jul 11
Posts: 843
Credit: 1,578,195
RAC: 665
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.
ID: 30996 · Report as offensive     Reply Quote
gyllic

Send message
Joined: 9 Dec 14
Posts: 136
Credit: 1,629,642
RAC: 2,619
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?
ID: 32412 · Report as offensive     Reply Quote
Alessio Mereghetti
Volunteer moderator
Project administrator
Project developer
Project tester
Project scientist

Send message
Joined: 29 Feb 16
Posts: 83
Credit: 1,037,458
RAC: 1,744
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...
ID: 32429 · Report as offensive     Reply Quote
computezrmle

Send message
Joined: 15 Jun 08
Posts: 604
Credit: 6,458,345
RAC: 15,791
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.
ID: 32430 · Report as offensive     Reply Quote
maeax

Send message
Joined: 2 May 07
Posts: 405
Credit: 13,676,254
RAC: 20,641
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?
ID: 32431 · Report as offensive     Reply Quote
1 · 2 · Next

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


©2018 CERN