Prentice,<br>As was said before, I don't believe that x64 processor architectures support 128 bit precision instructions either (I did glance through the official AMD manuals, and I've read the first 3 in the set for another project, and I can't recall anything about operating on variables that large; storing values of that precision, yes, but not multiplying and storing the results in registers). The results would overflow the registers and then you'd have to fall back on cache (which could be entirely doable, but you'd have to code in assembler to ensure that (a) the results don't fall out of cache and (b) that you are fetching the proper cache lines to obtain your results) or main memory (which would once again involve coding in assembly language). One way I think you might be able to do this is via some of the SIMD multimedia instructions built into the processor. I only gave that volume of the x64 (x86_64, AMD64, tomato-vs-tomato) manuals a cursory glance as that's never been my concern, but I do believe that the processor architecture does indeed support that level of precision and has the instructions to store the rather large results in contiguous registers. Of course, I don't know what this would do to your code.<br>

I'd suggest 4 things :<br>1) Order a set of the AMD64 manuals (they used to be free, not sure now) from AMD<br>2) Look at a cheap, brute force solution - I'd suggest SSD disks for swap, perhaps (that's the most likely way I can think of the performance degradation you're seeing happening - going out to swap - it's easy and cheap to test on one system, and if it reduces it to a more acceptable wall clock time then see if you can live with that)<br>

3) Find a project that utilizes the CPU's performance counters and measure exactly what is happening - it could be something quite simple that the compiler is doing wrong and you can fix w/ a few flags or a little bit of inline assembly code (I'm no FORTRAN programmer, but whatever standard you're using should support it if the compiler does, and most of them do)...I haven't done this in quite a while, perfctr used to be the standard. What's the current Linux best-practice standard?<br>

4) Start investigating other solutions in terms of CPU/GPU solutions (if it's that important)<br><br>That's my $0.02 USD that I can add to this discussion on very little sleep, I'll mail you if further inspiration hits with more espresso. I hope it helps. And I can't really comment of the feasibility of GMP libraries as I've never used them.<br>

Regards,<br>Derek R.<br><br><div class="gmail_quote">On Fri, Jun 25, 2010 at 9:28 AM, Prentice Bisbal <span dir="ltr"><<a href="mailto:prentice@ias.edu" target="_blank">prentice@ias.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Beowulfers,<br>
<br>
One of my Fortran programmers had to increase the precision of his<br>
program so he switched from REAL*8 to REAL*16 which changes the size of<br>
his variables from 64 bits to 128 bits. The program now takes 32x longer<br>
to run.<br>
<br>
I'm not an expert on processor archtitecture, etc., but I do know that<br>
once the size of a variable exceeds the size of the processors<br>
registers, things will slow down considerably. Is his 32x performance<br>
degradation in line with this?<br>
<br>
Is there any way to reduce this degradation? Would The GNU GMP library<br>
(or some other library) help speed things up?<br>
<font color="#888888"><br>
<br>
--<br>
Prentice<br>
_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
</font></blockquote></div><br>