FGRP5 - Huge Performance Difference Linux / Windows 11 24H2?

baracutio
baracutio
Joined: 18 Jan 05
Posts: 3
Credit: 997564
RAC: 1109
Topic 231899

Hello @all,

some weeks ago my notebook got the new Windows 11 24H2 package. Since then, I remember, WUs are taking almost twice the time than before. My system is a dual-boot machine, so I can directly compare it to Linux (Mint).

My machine is a Ryzen 7 5700U with 24GB RAM and I'm running only 2 WUs at the same time.

WU runtimes
on Linux: ~8.500 - 10.000 seconds
on Win11 24H2: ~16.000 - 20.000 seconds

What I noticed in the Stderr output for each task, that for Linux the flag info "Flags: X64 SSE SSE2 GNUC X86 GNUX86" is shown, but instead for Windows tasks it's "Flags: i386 SSE GNUC X86 GNUX86". Isn't there a flag for SSE2 missing?


Thanks for help & clarification ;)


Regards

 

My last tasks:

859345910 13207997 30 Dec 2024 13:26:47 UTC 30 Dec 2024 18:02:25 UTC Completed, waiting for validation 16,524.79 16,458.78 0.00 Gamma-ray pulsar search #5 v1.08 (FGRPSSE)
windows_intelx86
859345908 13207997 30 Dec 2024 13:26:47 UTC 30 Dec 2024 18:03:29 UTC Completed, waiting for validation 16,530.92 16,472.48 0.00 Gamma-ray pulsar search #5 v1.08 (FGRPSSE)
windows_intelx86
859073495 13207675 29 Dec 2024 18:33:37 UTC 29 Dec 2024 21:05:18 UTC Completed, waiting for validation 9,063.84 9,064.22 0.00 Gamma-ray pulsar search #5 v1.08 (FGRPSSE)
x86_64-pc-linux-gnu
859073428 13207675 29 Dec 2024 18:32:36 UTC 29 Dec 2024 21:04:16 UTC Completed and validated 9,069.99 9,070.46 693.00 Gamma-ray pulsar search #5 v1.08 (FGRPSSE)
x86_64-pc-linux-gnu
859033380 13207675 29 Dec 2024 15:48:56 UTC 29 Dec 2024 18:33:37 UTC Completed and validated 9,816.19 9,806.77 693.00 Gamma-ray pulsar search #5 v1.08 (FGRPSSE)
x86_64-pc-linux-gnu
859033370 13207675 29 Dec 2024 15:48:56 UTC 29 Dec 2024 18:32:36 UTC Completed, waiting for validation 9,809.10 9,799.58 0.00 Gamma-ray pulsar search #5 v1.08 (FGRPSSE)
x86_64-pc-linux-gnu

Mad_Max
Mad_Max
Joined: 2 Jan 10
Posts: 165
Credit: 2245485164
RAC: 653765

Yeah, also "i386" indicates

Yeah, also "i386" indicates that its a 32 bit app, while for Linux its 64 bit app (X64).
There is simply no 64-bit application for Windows at all (Linux has both variants).
 

But the real question is why there is still no version of the application compiled using AVX instructions, which are already available in all decent CPUs for many years and which can give up to a twofold increase in performance compared to SSE2 and very suitable for the type of computation FGRP5 doing.

And the likely answer is because the goal of maximizing productivity in this sub-project is not set at all. My impression of the entire FGRP5 sub-project is "we don't need a lot of CPU computing power at the moment, but we also don't want it to go to other BOINC projects, because we'll need it in the future, so let's figure out something to keep them busy for now".

Therefore, there is no GPU application, no use of modern CPU instruction sets, no 64-bit app for Win, outdated apps (last update in 2017y), etc. Because there is no goal to process this data as quickly as possible. On the contrary, so that it lasts for a very long time, keeps the excessive CPU computing power busy and at the same time does not require project staff to spend time on its maintenance while they are focused on other sub-projects.

AndreyOR
AndreyOR
Joined: 28 Jul 19
Posts: 27
Credit: 739187441
RAC: 1073048

Mad_Max wrote:... And the

Mad_Max wrote:

... And the likely answer is because the goal of maximizing productivity in this sub-project is not set at all....

It could simply be that the return they're getting with the app versions available is sufficient for them so they see no need or incentive to update the apps.  Looking at the Server status page, FGRP5 'Tasks in progress' and 'Workunits total' are much higher than the other sub-projects combined. Also, from one of Bernd's posts, I believe that one of the reasons for suspending BRP4G work is to redirect the CPU power to FGRP5.

There could also be a technical reason why there's no 64-bit Windows app (yet perhaps), like is the case with BRP7 CUDA being available on Linux but not Windows.

AndreyOR
AndreyOR
Joined: 28 Jul 19
Posts: 27
Credit: 739187441
RAC: 1073048

baracutio wrote:... My

baracutio wrote:

... My system is a dual-boot machine, so I can directly compare it to Linux (Mint). ...

I'd suggest you look into WSL2 (Windows Subsystem for Linux). It's a component of Windows and it uses very little resources compared to more traditional VMs.  This way you can run both Windows and Linux projects and/or tasks in a Windows boot.  I've used it a lot to do just that.  With a little additional work you can configure things so that you can control both BOINC clients via the Windows manager.

San-Fernando-Valley
San-Fernando-Valley
Joined: 16 Mar 16
Posts: 525
Credit: 10520267235
RAC: 4908972

+1

+1

San-Fernando-Valley
San-Fernando-Valley
Joined: 16 Mar 16
Posts: 525
Credit: 10520267235
RAC: 4908972

Mad_Max wrote: Yeah, also

Mad_Max wrote:

Yeah, also "i386" indicates that its a 32 bit app, while for Linux its 64 bit app (X64).
There is simply no 64-bit application for Windows at all (Linux has both variants).
 

But the real question is why there is still no version of the application compiled using AVX instructions, which are already available in all decent CPUs for many years and which can give up to a twofold increase in performance compared to SSE2 and very suitable for the type of computation FGRP5 doing.

And the likely answer is because the goal of maximizing productivity in this sub-project is not set at all. My impression of the entire FGRP5 sub-project is "we don't need a lot of CPU computing power at the moment, but we also don't want it to go to other BOINC projects, because we'll need it in the future, so let's figure out something to keep them busy for now".

Therefore, there is no GPU application, no use of modern CPU instruction sets, no 64-bit app for Win, outdated apps (last update in 2017y), etc. Because there is no goal to process this data as quickly as possible. On the contrary, so that it lasts for a very long time, keeps the excessive CPU computing power busy and at the same time does not require project staff to spend time on its maintenance while they are focused on other sub-projects.

You are hitting the nail on the head.

Please help them and do the re-coding.
I'm sure you have the time and knowledge to do it !

THANKS and happy crunching ...

sfv

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.