Fermi LAT Gamma-ray pulsar binary search "FGRPB1" - new app versions

Der Mann mit der Ledertasche
Der Mann mit de...
Joined: 12 Dec 05
Posts: 151
Credit: 302,594,178
RAC: 0

Quote:Bernd Machenschalk

Quote:

Bernd Machenschalk wrote:

Sorry. You might agree that it's pretty hard to please everyone.

It would help, I guess, to find out on which systems the 1.05 runs faster and on which it's slower, so I can implement an automatic selection independently of the manual "Beta" one.

Yes, but in former times we have had a Website wich was able to search by an app selection and counting pending's, valid's, invalid's and error's. That would help a lot to find out bad WU's, App's and Hosts!

Sorry, but in other Postings here are running a Discussion about "look and feel" of the new Website but the Basic Tools from the old Site are still not working after about 8 Weeks since changing this Site.

Greetings from the North

Jasper
Jasper
Joined: 14 Feb 12
Posts: 63
Credit: 4,032,891
RAC: 0

Bernd Machenschalk wrote:It

Bernd Machenschalk wrote:

It would help, I guess, to find out on which systems the 1.05 runs faster and on which it's slower, so I can implement an automatic selection independently of the manual "Beta" one.

I wonder, the issue seems to be with the happy Linux users, like it happened before? I don´t have an overview of it all, just judging on AgentB´s and Gary´s systems...

Couldn´t you apply what was needed to solve that problem to create 1.04 for Linux earlier? If that works - famous last words - FGRPB1 could go in production again and not rely on beta testing at all anymore. Yes, I know, it seems like some work for about less than a month left with cuda55 / Parkes PMPS XT crunching. However, at the same time, it wouldn´t rely on people reading here to get the benefits of more efficient crunching, if it could just go in production state again?

AgentB
AgentB
Joined: 17 Mar 12
Posts: 915
Credit: 513,211,304
RAC: 0

Bernd Machenschalk

Bernd Machenschalk wrote:
Sorry. You might agree that it's pretty hard to please everyone.

 I agree, then again i might disagree just to prove you are correct Tongue Out.  Just to be both inconsistent and consistent.

Quote:

It would help, I guess, to find out on which systems the 1.05 runs faster and on which it's slower, so I can implement an automatic selection independently of the manual "Beta" one.

 OK I have another not faster one.  On this i7-860 host 4918234.

Application     N     Average        Median      Minimum        Maximum StdDeviation

FGRPB1v1.00  1346      28098.1      28052.7      22377.86      43664.31 2144.33
FGRPOLDv1.01   46      28193.2      27672.8      23603.95      32379.21 2160.72
FGRPSSEv1.03   76      33262.2      33352.5      29386.59      35967.80 1536.24
FGRPSSEv1.04   33      29007.7      29040.81     24787.41      33561.67 2502
FGRPSSEv1.05   29      30696.9      30500.81     29145.24      33279.06 1099.18

Progress only comes when things change, and i quite like it when things change.  You always go slower on the bends.   I think it's amazing that E@H works, and keeps on working.

 

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,297
Credit: 246,179,899
RAC: 10,667

Jasper_7 wrote: I wonder, the

Jasper_7 wrote:

 

I wonder, the issue seems to be with the happy Linux users, like it happened before?

 

 

I can confirm from the DB that indeed almost all hosts that don't benefit from 1.05 are running Linux. So for the time being I made 1.05 the default again for all non-Linux platforms.

This indeed looks like a compiler issue again, but if it's comparable to the previous issue, it must be the other way 'round - the 1.05 Linux app version was definitely built with the same compiler version than the 1.04.

BM

Darren Peets
Darren Peets
Joined: 19 Nov 09
Posts: 37
Credit: 101,129,000
RAC: 27,159

I had a look at my results.

I had a look at my results.  Computer is 64-bit Linux, SSE2, 4 tasks running on 4 physical cores (after finding that 4+4=4.5 for GW tasks):

1.00:  ~17500s (2 tasks still visible)
1.01:  16800s (1 task still visible)
1.03:  22300s (1 task still visible)
1.04:  0 tasks still visible
1.05:  ~20500s

And my recollection is these tasks used to take ~4.5h, consistent with the surviving 1.00 and 1.01 examples.  So that 2% increase in time at 1.03 seems a bit larger than 2%, but 1.05 may bring the time partway back down.  Tasks 1.03 and above are labelled FGRPSSE -- should I expect this to say SSE2 instead?  

Sebastian M. Bobrecki
Sebastian M. Bo...
Joined: 20 Feb 05
Posts: 63
Credit: 1,529,590,722
RAC: 74

I see that 1.05 have

I see that 1.05 have relatively high needs for memory bandwidth. On a two socket system, based on Intel quad core CPU with relatively low clock (2.27GHz), running 8 task parallel (4 task on each, so no HT usage) it uses more than ~10GB/s per socket memory bandwidth:

          |  READ |  WRITE |
---------------------------------------------------------------------------------------------------------------
 SKT   0    10.85     1.91         
 SKT   1    10.33     1.69         
---------------------------------------------------------------------------------------------------------------
       *    21.18     3.60         

So this system have relatively low clock and a triple channel DDR3 memory so it perform quiet well, but I think that a more modern ~4GHz CPU with only two memory channels, even with DDR4, may be memory bandwidth starved.

Jasper
Jasper
Joined: 14 Feb 12
Posts: 63
Credit: 4,032,891
RAC: 0

Darren Peets wrote:I had a

Darren Peets wrote:

I had a look at my results.  Computer is 64-bit Linux, SSE2, 4 tasks running on 4 physical cores (after finding that 4+4=4.5 for GW tasks):

1.00:  ~17500s (2 tasks still visible)
1.01:  16800s (1 task still visible)
1.03:  22300s (1 task still visible)
1.04:  0 tasks still visible
1.05:  ~20500s

And my recollection is these tasks used to take ~4.5h, consistent with the surviving 1.00 and 1.01 examples.  So that 2% increase in time at 1.03 seems a bit larger than 2%, but 1.05 may bring the time partway back down.  Tasks 1.03 and above are labelled FGRPSSE -- should I expect this to say SSE2 instead?  

You  should disable beta testing for that host. That way, you will not get the 1.05 version anymore, but hopefully and likely the for Linux better 1.04 (for now).

Darren Peets
Darren Peets
Joined: 19 Nov 09
Posts: 37
Credit: 101,129,000
RAC: 27,159

1.04:  ~15800s (15

1.04:  ~15800s (15 tasks)

OK, yes, there may be an issue with 1.05 on this platform.  

Oliver Behnke
Oliver Behnke
Moderator
Administrator
Joined: 4 Sep 07
Posts: 961
Credit: 25,169,626
RAC: 3

A quick update: Bernd isn't

A quick update: Bernd isn't available this week and we're preparing the next GW analysis run with high priority. We're going to look into the compiler/optimization issue on Linux again when he returns, so please bear with us.

Thanks,
Oliver 

 

Einstein@Home Project

ExtraTerrestrial Apes
ExtraTerrestria...
Joined: 10 Nov 04
Posts: 770
Credit: 555,707,183
RAC: 166,894

Sebastian M. Bobrecki wrote:I

Sebastian M. Bobrecki wrote:

I see that 1.05 have relatively high needs for memory bandwidth.

That makes sense: the look-up table has to be used intensively, otherwise it woudln't help speeding things up (normally). and we know from Bernds post it's requiring about 100 MB of RAM (per instance), i.e. a lot more than any current CPU cache offers, so those values must be fetched from main memory.

MrS

Scanning for our furry friends since Jan 2002

Comment viewing options

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