[QUOTE=axn;274837]
128-bit floating point implemented in hardware could speed up LL testing by 2x. Even implemented in microcode, it could potentially speed it up by 25%.[/QUOTE]

You may be right, but I did not see any 128-bit-FPALU in RL yet. Maybe there are, but I don't know of any.

[QUOTE=LaurV;274828]I don't believe OP was asking about memory width. I took it like CPU register size, and since my previous post.

<snip>

Maybe we will never go to more then 64 bit addressing space, as said before, this is more then enough for how much memory one can have in its box,

<snip>

The question is if this would speed up searching for huge primes. My answer stands: with the current algorithms, most probably not, or not so much. Having a 3x or 4x speed for TF means nothing, you could do one or two bits more. The real gain would come from discovering new algorithms, as somebody said on a [URL="http://www.mersenneforum.org/showpost.php?p=274344&postcount=25"]parallel thread[/URL].[/QUOTE]

It is so refreshing to read common sense!!!! But I [b]strongly[/b] doubt
whether a faster algorthm than LL exists.

128-bit registers would help somewhat, but would only be a constant factor
speedup. And that can easily be obtained now by additional cores --> no
architectural changes required.

There is no [i]market[/i] today (well, almost no market) for a machine with
128-bit registers. Think about the economics of developing such a
processor.

OTOH, there is a small market for perhaps a 128-bit arithmetic coprocessor
implemented as (say) a PCI card. But if I were to develop such a device,
I certainly would not limit it to 128-bits. I'd build a board level coprocessor
with (say) 1024-bit registers. In fact, when I was at MITRE we designed
and built a VMW-based board (done in prototype wire-wrap using TI DSP
chips) that implemented 1024-bit arithmetic as a coprocessor to a SPARC.
[It was just a research project].

I strongly doubt whether there is sufficient demand to make development
of a commercial MP processor economically viable.

GIMPS has no real practical importance. It will find the next prime when it
finds it. Patience!

[QUOTE=Dubslow;274833]Well, even from a memory standpoint, I wouldn't be surprised if it became necessary sometime way off in the future. I'm sure someone in the late 40's/early 50's said &quot;we'll never ever get anywhere close to 4 GB of memory, 32 bits is more than enough&quot; and look at where we are now.[/QUOTE]

When IBM designed the system 360 in the 1960s they said 24 bits would be enough. As a ex systems programmer on the platform's successors I can testify that was *big* a mistake. It was subsequently extended, first to 31 bits (don't ask why not 32), then to 64 bits. But with lots of 24 bit only code still around the complications it caused were a big pain.

Chris K

[QUOTE=R.D. Silverman;274870] There is a small market for perhaps a 128-bit arithmetic coprocessor
implemented as (say) a PCI card. But if I were to develop such a device,
I certainly would not limit it to 128-bits. I'd build a board level coprocessor
with (say) 1024-bit registers.[/QUOTE]

The most likely market would be for a public key accelerator doing 1024 or 2048 bit arithmetic. As long as it's not crippled to limit the max data length it would be helpful.

Chris K

[QUOTE=chris2be8;274890]The most likely market would be for a public key accelerator doing 1024 or 2048 bit arithmetic. As long as it's not crippled to limit the max data length it would be helpful.

Chris K[/QUOTE]

We already have such hardware. Banks use it. Current performance is more than adequate.

Moreover, the highest-end hardware security modules used by banks have about one-third the performance of an i7/2600 CPU when doing 1024-bit or 2048-bit RSA (I have a friend who works for a company that makes them).

[QUOTE=fivemack;274894]Moreover, the highest-end hardware security modules used by banks have about one-third the performance of an i7/2600 CPU when doing 1024-bit or 2048-bit RSA (I have a friend who works for a company that makes them).[/QUOTE]

"A company"? I presume that you mean IBM.

This reminds me, AVX is supposed to support 512- and 1024-bit registers in the future. But whether we will actually have them remains to be seen.

A modern FPGA might be fast enough to implement the 1024-bit arithmetic coprocessor your thinking about R.D. Silverman. Perhaps we should stick with 64-bit commodity hardware instead :smile: . Commodity hardware is highly optimized and might/probably will outperform a custom design on an FPGA anyway.

[QUOTE=R.D. Silverman;274898]"A company"? I presume that you mean IBM.[/QUOTE]

nCipher (now Thales) of Cambridge; make 'hardware security modules', maybe more for internet than banking businesses but also sell to (for example) the UK Passport Agency

[QUOTE=E_tron;276108]A modern FPGA might be fast enough to implement the 1024-bit arithmetic coprocessor your thinking about R.D. Silverman. Perhaps we should stick with 64-bit commodity hardware instead :smile: . Commodity hardware is highly optimized and might/probably will outperform a custom design on an FPGA anyway.[/QUOTE]

I spent quite a while both in amateur and professional contexts contemplating large multipliers on FPGA, and could never get them to be remotely performance-per-pound competitive with Opterons. The individual multipliers are small and slow (25-bit x 18-bit, both signed, feeding a 48-bit accumulator, running at 638MHz), so you need about sixty of them to compete with one Opteron core, and the price of a single FPGA dev board gets you a complete off-the-shelf box with 48 Opteron cores.