Manual results check-in is temporarily broken

[bayanne]

The result that I e-mailed to George yesterday is still appearing on the team report as work to do.

If George is having to process each of these one of results manually it surely is taking a lot of effort on a one by one basis.

Why not set a limit of a maximum of 5 results that can be submitted at any one time using the old method whilst a new system is set in place.

You might start dissuading people from crunching if they cannot see their work being recognised quickly

[nitro]

Originally posted by bayanne
The result that I e-mailed to George yesterday is still appearing on the team report as work to do.

If George is having to process each of these one of results manually it surely is taking a lot of effort on a one by one basis.

Why not set a limit of a maximum of 5 results that can be submitted at any one time using the old method whilst a new system is set in place.

You might start dissuading people from crunching if they cannot see their work being recognised quickly

5???? I was checkinh in thousands at a time.

As to your last part, your right, it did, after over 2 years doing that I just switched 2 boxes off. It's becoming too much trouble.

[bayanne]

For LMH results I have always e-mailed these to George, as there was no stats 'fix' involved

I am more thinking about those who would normally use the manual check-in for non Windows/Linux boxen when they complete a DC or LL.

[Paulie]

Originally posted by gbvalor
On the other hand. Is Dual G5 really a two processors like chip?. Have you tried a two-way threaded Glucas on it?

Guillermo

I went to an Apple store, and I quickly ran multi-threaded Glucas on the G5.

See: http://www.mersenneforum.org/showthr...&threadid=1220

[gbvalor]

I went to an Apple store, and I quickly ran multi-threaded Glucas on the G5.

See: http://www.mersenneforum.org/showth...p;threadid=1220

Err... I think I have to change some memory chips in my brain.

Have you tried latest code. You can get latest snapshot here:

http://www.oxixares.com/~gbv/glucas/...0031209.tar.gz

It would be interesting to see whether it goes faster or slower than the ancient v.2.9.0. I've had not available ppc hardware lastly. I got some access problems at sourceforge compile farm.

Guillermo.

[S00113]

Originally posted by TauCeti
Wow! Awesome! How about trying a multithreaded glucas on the SuperDome?

I do, but Glucas doesn't work with more than 4 CPUs. Profiling shows that it is also very poorly optimized for the Itanium 2. The compiled code has one fma and two nops for each word in radix_8_dif, where most CPU time is spent. Glucas also lack code for the correct cache line size on the Itanium 2. It doesn't seem to do prefetching either, at least not correctly. There is a very high number of latency cycles in ldfd- and stfd instructions where the data should be cached in L2 or L3 cache if prefetching worked.

To quote gbvalor:

It would be most interesting, what iteration times M40 would produce on the Dome.

Haven't tested M40, but here is a typical line for 21591599 on 4 CPUs:

Iter. 7820000 ( 36.22%), Err= 0.000, 794.10 user 397% CPU (0.020 sec/iter).

But, as I mentioned, there is a lot of room for improvement by optimizing for Itanium 2. Running on all 64 CPUs would also be cool.

[Xyzzy]

FYI:

I submitted a 4000 line results.txt via the manual page tonight... It took forever, but it worked...

[gbvalor]

I do, but Glucas doesn't work with more than 4 CPUs.

It sounds like a bug . Actually, it was more than two years ago last time I had the chance to work in a more than 4-processors machine. And a lot of code wrote since then.

Profiling shows that it is also very poorly optimized for the Itanium 2

Indeed, I wrote the code for Itanium, and for those processors prefetch worked miserabily. So I had to write tones of code with preload better than prefetch. Prefetch is disabled for Itanium family. I think it could be enabled with no many work. I will try it next year (soon). But I will need the help of S0013.

there is a lot of room for improvement by optimizing for Itanium 2

Sure.

Guillermo.

[ewmayer]

The kinds of suboptimal things you're seeing in terms of the compiler-generated machine code for IA64 under Linux probably explains the nearly factor-of-2 difference Guillermo and I have have been seeing for both our codes between IA64/Linux (using the Intel C compiler) and IA64/HPUX (using the HP C compiler.) Intel C appears to be doing a pretty crappy job with IA64-oriented floating-point optimizations.

OTOH, Intel C correctly and decently-well compiles my integer-based factoring code whereas I'm running into compiler bugs there with HP C, so I'm not going to complain too loudly about the former - mainly, I hope the compiler group at Intel releases a performance-improved version soon.

[GP2]

Unfortunately, Itanium has sold only a few thousand processors in total, and the eventual Intel version of x86-64 may finally kill it. In purely numerical terms of installed base population, the G5 may be more significant.

Any chance of Glucas and Mlucas working automatically with PrimeNet anytime soon?

[gbvalor]

Any chance of Glucas and Mlucas working automatically with PrimeNet anytime soon?

We first need to know how to talk with server. I will put my hands on it when first drafts of API server were sent to us.

And happy new year 2004!!

Guillermo.

[nomadicus]

Originally posted by GP2
Unfortunately, Itanium has sold only a few thousand processors in total, and the eventual Intel version of x86-64 may finally kill it.

If itanium were killed at the server level too (which I seriously doubt will happen), that might resurect Alpha and save it from the jaws of stealth marketing. (I know, I know, it is a pipe[line]-dream.)