Some questions regarding the client

[TauCeti]

I know that i am notoriously curious, but i cannot restrain me to ask some more questions:

- Are the inner loops of the client hand-coded or is the whole client compiled from a (c++?) source?

- If the client is compiled: what compiler did you use? MSVC? If MSVC: did you ever try to compile the source with another (Intel, GCC) compiler for performance enhancements? OK... i admit a lot of 'ifs' here

- does the server actually use the statistical information the client sends back (relative times for init, sieve small, sieve medium, sieve large, resieve...) to send specific workloads for the clients optimized for their L1, L2, L3 and bandwith footprint?

- Would it make sense to compile special (optimized) versions for the different CPUs? I am still wondering what little (relative) impact the actual CPU frequency has on the performance of the client. Is memory prefetching used in the client?

- are the relations checked when the clients send them back? The more participants NFSNET gets and the longer the projects run, the higher is the possibility that some 'bad guys' try to spoil the fun sending back faked results. If those faked results could make the LA-stage unsolvable it would be _very_ bad indeed...

Ooops - enough for now...

Tau

[Wacky]

Originally Posted by TauCeti

I know that i am notoriously curious, but i cannot restrain me to ask some more questions:

Your questions are certainly of interest to many "curious" participants.
I would suggest that they might be better answered on the nfsnet-l mailing list which reaches all the participants and not just those interested in Mersenne numbers.

Originally Posted by TauCeti

- Are the inner loops of the client hand-coded or is the whole client compiled from a (c++?) source?

I don't know how to answer this. The code was not produced by some machine translation (like yacc or Fortran), so I would have to say that it is "hand coded". But that also applies to most C++ code also.
On the other hand, only a very small part of the code, and then only on certain platforms, is written in Assembler. The majority of the code is written in C, rather than C++.

Originally Posted by TauCeti

- If the client is compiled: what compiler did you use? MSVC? If MSVC: did you ever try to compile the source with another (Intel, GCC) compiler for performance enhancements? OK... i admit a lot of 'ifs' here

"If the client is compiled" -- Of course it is compiled. I cannot imagine it being interpreted.

As for the compiler, that depends on the platform.

Originally Posted by TauCeti

- does the server actually use the statistical information the client sends back (relative times for init, sieve small, sieve medium, sieve large, resieve...) to send specific workloads for the clients optimized for their L1, L2, L3 and bandwidth footprint?

Those stats have been valuable in the siever design, but are not used in the day-to-day operation. The server, per se, doesn't care about the client cache sizes. It bases its assignment size on the processing rate. The only factor that the server might need to consider is available memory. We haven't gotten there yet, but we might wish to run projects in parallel and assign "simpler" projects to the smaller machines.

Originally Posted by TauCeti

- Would it make sense to compile special (optimized) versions for the different CPUs? I am still wondering what little (relative) impact the actual CPU frequency has on the performance of the client. Is memory prefetching used in the client?

There is really only one part of the code that is significantly affected by the cache size. Each "line" spans a group of "a" values that is too large to fit in the caches. On most architectures, the client code reads the cache sizes from the CPU. The inner loop size is chosen to subdivide that line into pieces of an appropriate size to be "cache friendly". A significant amount of time has been spent in making the siever fast and efficient. "Tricks", such as prefetch, are used extensively.

Originally Posted by TauCeti

- are the relations checked when the clients send them back? The more participants NFSNET gets and the longer the projects run, the higher is the possibility that some 'bad guys' try to spoil the fun sending back faked results. If those faked results could make the LA-stage unsolvable it would be _very_ bad indeed...

We do not check the relations immediately. However, they are screened periodically. Since we track the contributor of each (proposed) relation, we can easily discard fake contributions. As it is, we already discard the very few relations that have somehow gotten corrupted. At worst, we might get a false sense of progress until we catch the fakes at the checkpoint. There are some other "features" in the system to address these problems. But, on a cost - benefit basis, they are not an efficient use of our present resources and therefore not active. If conditions change, so may our procedures.

In any case, the nature of the Number Field Sieve method "protects" us from bogus results in that each relation submitted is really just a hint toward the solution and it is the total number, rather than any particular one, that is important.

[TauCeti]

Originally Posted by Wackerbarth

Your questions are certainly of interest to many "curious" participants.
I would suggest that they might be better answered on the nfsnet-l mailing list which reaches all the participants and not just those interested in Mersenne numbers.

Thinking about it, i agree. But i did not get a lot of traffic in the list the last weeks and so i assumed that most participants had moved to this forum (like it is with prime95).

Originally Posted by Wackerbarth

"If the client is compiled" -- Of course it is compiled. I cannot imagine it being interpreted.

Hmm.. i was thinking about coding assembler (humans do the 'compiling') vs. coding in a high-level language (c/c++).

And finally the CPU does _interpret_ the assembler code!? To actually compile that code the CPU would have to reconfigure it's hardware according to the code (still some years ahead of us). Imho the terms compiling and interpreting depend on your viewpoint. (ok, i admit the flaw in my original question, but the distinction between compiling and interpreting is not that sharp nowadays)

Originally Posted by Wackerbarth

In any case, the nature of the Number Field Sieve method "protects" us from bogus results in that each relation submitted is really just a hint toward the solution and it is the total number, rather than any particular one, that is important.

Hmmm... Then let me ask another question:

I have got the Crandall/Pomerance and still struggle to understand the QS. But i think i understand the part how to calculate the number of relations to be reasonable sure to get the final solution. Now the question: Is the set of relations below that threshold (e.g. only 75% of the required # of relations) 'worthless', or is there a probability (below 1) that we could find a solution even with a underdetermined matrix. I have the feeling, that the answer to that question turns out to be very simple but i am unable to answer it.

[Wacky]

Originally Posted by TauCeti

Thinking about it, i agree. But i did not get a lot of traffic in the list the last weeks and so i assumed that most participants had moved to this forum (like it is with prime95).

That is the reason that I was opposed to the formation of this forum.
Frankly, I hate the format. To me, an email list is far superior.

[ColdFury]

or is there a probability (below 1) that we could find a solution even with a underdetermined matrix

Yes, but nobody wants to go thru all that linear algebra just to not find a solution. Sieving is (relatively) cheap, so it's better to do more sieving and insure we'll get a solution.