Estimate the new primes

[drew]

Originally Posted by R. Gerbicz

You are a little impatient!
I would wait for independent verifications on a Commodore64.

Oh gosh, could you imagine?

I'm trying to visualize the stack of 5 1/4" floppies needed to store the data (since 64k is far short of the 5+ Megabytes required to store the result).

Let's see if anyone can figure out how many times someone would need to change floppy disks per iteration. And how far into the test will the original floppies start to wear out?

[mcduck]

Originally Posted by R. Gerbicz

You are a little impatient!
I would wait for independent verifications on a Commodore64.

Does mlucas compile on the iphone? :P

[retina]

I've still got a working ZX81 with 16kB expansion pack and a tape recorder. Can someone tell me the exponents and I'll run quick a double check on them with the ZX81.

[cheesehead]

Consider doing with the Commodore64 just what we're doing with the modern Sun monsters: parallel processing. Line up (or maybe arrange them in a square, or cube) 64 or so of the '64s -- provided we can find that many still in working order, of course.

Originally Posted by drew

I'm trying to visualize the stack of 5 1/4" floppies needed to store the data (since 64k is far short of the 5+ Megabytes required to store the result).

According to the Wikipedia article http://en.wikipedia.org/wiki/Floppy_disk, formatted storage capacities of 5¼" floppies ranged from 89.6kB to 1,182,720 bytes (disregarding the 5¼-inch Perpendicular). Let's assume your C64 can handle the 720kB ones. We'd need 8 of them to store a 42M exponent.

Let's see if anyone can figure out how many times someone would need to change floppy disks per iteration.

That would depend on whether the software could do 1/8 of each FFT "in-place". If so, then each floppy need be inserted only once per iteration. (The software would read 1/8 of the FFT from the floppy, perform that part of the transform, then write the result back onto the same floppy.) There would be a total of 8 changes per iteration. However, that's really impossible, because each 1/8 section of the FFT result depends on all 1/8 sections of the FFT input. So we'd need at least 64 changes. But it's worse than that -- intermediate results would have to be written and read. I'll guess that 8 times that many changes -- 512 -- would be needed.

Edit: Oops, I forgot that the FFT is longer than just the binary-bit exponent. If it's a 4096K FFT, that's 4096K x 8 bytes = 32MB. Multiply all numbers of floppies (and changes) elsewhere in this posting by 6.

But I think (I'm getting a bit confused here) that might be per C64, so 64 x 512 = 32,768 changes for the entire array ... per iteration.

And how far into the test will the original floppies start to wear out?

Well, we'll have to rotate new floppies in at regular intervals. Also, it'd be a good idea to make a backup copy of each iteration's result to be set aside in case of need. That would imply using a fresh floppy each iteration, so we won't have to worry about wearout ... but we do have to worry about where we're going to get several billion 5¼" floppies in mint condition.

Also, we'll need to devote half of the Commodore64s to simple copying duty. Either find 64 more of them in working order, or cut our throughput in half.

[Damian]

Originally Posted by R. Gerbicz

You are a little impatient!
I would wait for independent verifications on a Commodore64.

I had just made a little application for double checking on any java enabled phone.

You can download it here

LLMidlet jad
LLMidlet jar

[Uncwilly]

You forget about the C64's expansion/cartridge port. That and a little extra custom harware and you could make a cluster. They can access the memory on the cartridge and main memory.

[ET_]

Originally Posted by Uncwilly

You forget about the C64's expansion/cartridge port. That and a little extra custom harware and you could make a cluster. They can access the memory on the cartridge and main memory.

I'm afraid not. C64 could address a maximum of 16 bit space (65536 bytes). The address space from 0K to 1K was reserved by the interrupt vector (IIRC) and locations from 40960 to 49152 had the resident operating system. If you add some routines to perform base-index addressing (like on the 8086) and wipe off the resident BASIC you'll be forced to work with machine language only.
You could also shrink the vector table eliminating sprite generators and sound controllers.

I should have a C64 emulator somewhere in my archives, running at approx. 6-10 MHz: putting 4 of them on a quad-core environment and letting them communicate could be a good exercise...

Luigi

[Nelson]

Originally Posted by ET_

<snip>
I should have a C64 emulator somewhere in my archives, running at approx. 6-10 MHz: putting 4 of them on a quad-core environment and letting them communicate could be a good exercise...

Luigi

Good??? Interesting though. I Predict we will have discovered a 150 million digit prime before the verification is complete on any of the early home computers even the original PC.

nelson

[ET_]

Originally Posted by Nelson

Good??? Interesting though. I Predict we will have discovered a 150 million digit prime before the verification is complete on any of the early home computers even the original PC.

nelson

nelson, I was joking...

Luigi

[Uncwilly]

Originally Posted by ET_

I'm afraid not. C64 could address a maximum of 16 bit space (65536 bytes). The address space from 0K to 1K was reserved by the interrupt vector (IIRC) and locations from 40960 to 49152 had the resident operating system. If you add some routines to perform base-index addressing (like on the 8086) and wipe off the resident BASIC you'll be forced to work with machine language only.

IIRC one could do something like bank swapping, address main memory then turn off access to main and access the cartridge. One can copy between cartridge and main memory. Maybe the Vic20 would be a better bet. They do have external memory expansion available.

Maybe a TI99/4A would be better.

[ET_]

Originally Posted by Uncwilly

IIRC one could do something like bank swapping, address main memory then turn off access to main and access the cartridge. One can copy between cartridge and main memory. Maybe the Vic20 would be a better bet. They do have external memory expansion available.

Maybe a TI99/4A would be better.

I used bank swapping on Commodore 128...

Ah, the good ol' times of SYS64738...

Luigi