Prime Number Generator

OK, the contest is to generate 100 thousand unique Prime numbers from 2^32 to 2^64-1 in the shortest time possible. There are some limits of course.

1. You cannot load any values from external files.
2. Your entire program must be contained in a single cpp file of less than 64K named PrimeFunc.cpp with a function named PrimeFunc(__int64*) which will be called by the test program.
3. You may use no more than 10 'seed' values none of which may be greater than 2^32-1
4. All code must compile under visual studio 2008 express as a win32 console program. Default optimzation settings will be used.
5. All results must be placed into the __int64* array supplied by the test program.
6. You may not use any file or network access functions.
7. You may use inline assembly, OpenMP, threads, even the GPU as long as you limit GPU code to HLSL.
8. There can be no composite numbers returned
9. You must return exactly 100 thousand primes, no more no less.
10. Programs that crash are disqualified.
11. Programs that take more than 5 minutes to complete are disqualified.
12. Entries should be made public.
13. This contest is open ended so further optimizations should be submitted as a new entry.
14. (Optional)The solution should be general enough so that it could in theory be applied to build a comprehensive list of all primes.
15. You may not include any header files other than <math.h>, some exceptions may be made to this ask first.

The test system is a Pentium 4HT 3.2 GHz with 2GB of 800MHz dual channel memory. The GPU is an 8600 with 1GB of ram. A non-optimized test program was run and completed within the alloted time.

How will you be verifying the correctness of the returned values?

>> 3. You may use no more than 10 'seed' values none of which may be greater than 2^32-1

Does it not make sense to start from the first number in the range you require?

the test program will verify the values in the array after the PrimeFunc() returns.. It will test every value both for uniqueness and for primality.

The testing phase of the program is not counted against the runtime of the function.

Starting from 2^32+1 is fine, since it is not prime. By seed value I mean specifically prime numbers or precalculated values used to circumvent doign the actual calculations. Some algorithms require seedign with known primes to operate efficiently, so I allow the use of 10. The rule is to prevent someone from just writing a huge array with all the values and returnign it.

Do we have to write it in C++?

Quote:

---

Originally Posted by zacs7

Do we have to write it in C++?

---

as stated, you can also use inline assembly or HLSL. No C# python or java if thats what you mean.

here is an example of one possible solution.

I think he wanted to ask can we do it in plain C.
2. - Can't we use unsigned long long instead of int64? I'm somehow safer with it.
4. - Why not use mingw? And what's with the optimizations?

RSA Encryption
Your Going Down baby

Quote:

---

Originally Posted by hauzer

I think he wanted to ask can we do it in plain C.
2. - Can't we use unsigned long long instead of int64? I'm somehow safer with it.
4. - Why not use mingw? And what's with the optimizations?

---

yeah plain C is fine.

you can recast the function call internally if you want, but the test program is already written and the test procedure will just invovle drag drop compile and run.

Code:

---

void YourFunc(long long*);
 
void PrimeFunc(__int64* blah){
  YourFunc((long long*) blah);
  return;
  }
 
void YourFunc(long long* blah){
  return;
  }

---

is fine

and im not using mingw because I use VS. I stated what compiler so that you know what compiler specific extensions you can and cant use.

The default optimizations on my compiler are compile for speed and it uses the static multithreaded runtimes if thats important, it shouldnt be.

Where do we need to send our entrys?

just post them here, its an open ended contest, so no need to keep secrets

Can we use the network card, if you catch my drift? :-)

@abachler: Ok, all good.

Quote:

---

Originally Posted by zacs7

Can we use the network card, if you catch my drift? :-)

---

Sure as long as you follow rule #1 and #6, by all means use teh PIC on the NIC to crunch numbers :)

and good luck accessign it without breakign rule #15 or #2 part b

oh as far as teh earlier statement that plain C is ok, its OK as long as it will compile as C++ code. So make sure you use explicit recasts. Im not going to edit your code to get it to compile.

Quote:

---

Originally Posted by abachler

2. Your entire program must be contained in a single cpp file of less than 64K named PrimeFunc.cpp with a function named PrimeFunc(__int64*) which will be called by the test program.
5. All results must be placed into the __int64* array supplied by the test program.

---

Instead of __int64, I suggest that you go with something like sqlite3_int64.

Quote:

---

Originally Posted by abachler

15. You may not include any header files other than <math.h>, some exceptions may be made to this ask first.

---

In C++ that should be <cmath>. Actually, why not just allow the C and C++ standard libraries?

Its __int64 and thats final. If you want to recast it inside your function go ahead, but the interface is set in stone. Sorry if thats a bit blunt but there has to be one set interface or Ill end up rewriting the test program for every entry. If I do it for one person ill end up doing it for everyone.

If you have need of a specific header file state what you need, don't ask me to open it up for no reason. The only exception that comes to mind are the headers for OpenMP or for DirectX(HLSL). I see no reason that any other headers shodul be needed, but liek I said, if you need a specific header file, ask first.

Why you would use HLSL for this is beyond me.

gpgpu.org
thats why.

That will only work on DX10+ or possibly even DX11 when compute shaders are introduced. As of right now there would not be a way to transfer the 100 thousand prime numbers back to the software. That would require a ton of floating point textures and a ton of surface locks to read the values. NVidia Cuda is only available in 9+ series cards and is going to be used with their acquired PhysX chips on the video card.

Quote:

---

Originally Posted by Bubba

NVidia Cuda is only available in 9+ series cards and is going to be used with their acquired PhysX chips on the video card.

---

Wrong, all 8XXX Geforce cards support both PhysX and CUDA, including Abachlers 8600GT. PhysX requires 256MB of dedicated VRAM though so integrated cards won't do PhysX, only CUDA...

There is also RapidMind, which I also have installed along with CUDA.

I'd be interested to see how you are going to get 100 thousand primes off of the video card and back into software. Shaders are not meant to communicate back down to the software level - at least not until DX11 and even then I'm a bit fuzzy on the compute shaders functionality.
You could render the primes to a floating point texture but that would be completely inefficient. In the current architecture this does not sound like a good idea. I'm not saying it's not possible but it goes against the design of the shader paradigm...for now.

I would think using SSE2/3/4? would be a better choice than HLSL.

Quote:

---

I would think using SSE2/3/4? would be a better choice than HLSL.

---

Depending on exactly which CPU he has, SSE3 might not even be available (SSE4 was introduced in Penryn, so we can forget about it, but I don't think it would have been useful anyway).

abachler, are you running a 32 or 64 bit OS ? Some Pentium 4 support the x86-64 ISA, some don't.

Oh and I tought CUDA wasn't supported by Visual Studio 2008 express edition. Well.

Oh, and what are we winning ? :)

Its a matter of the number of shaders available, operating in parallel, which amortize the innefficiency of the actual operation to produce superior absolute throughput.

SSE3 is available, but VS2008 only supports SSE2.

Well, CUDA is installed, but it is limited to the low level API, I havent fulyl explored what those limits are, so I will have to get back to you on that. I believe the full API requires 2005 or 2003, neither of which I have.

The versions I run are 4.0 for 80 bit long double access, 6.0 , and 2008 because its free.

I have CUDA 2.0 Final installed, and RapidMind 3.1 ( ineed to check for a new versin fo that).

Here's my entry. It follows the contest rules. I'm targeting the best user-time possible.

Oh man, what a waste of time.

Violates rules 1 and 6 (no external files, no file access functions).

It also takes longer than the original code it was based on. Probably due to setting up the file mapping.

Ah well, I decided to give it a try with an obvious brute force implementation. Note that as this is in C++, I have included <cmath> instead of <math.h>.

Interestingly, switching from std::sqrt() to the method that abachler advocated in this Prime numbers thread made no difference (it was only very marginally worse, and that could have just been due to timing inaccuracy). Therefore, it would have been better (according to my timings) to just not include any headers at all and use that method, but I decided to go with my original method anyway.

EDIT:
hmm... I think that 3 is not actually a seed value in my case since I am testing it for primality, hence I am uploading a modified version that has just one seed value, namely, 2.

well, the actual contest is to generate primes greater than 2^32. I changed one line of your code (the typedef) so it woudl compile. Other than failign the magnitude test it looks like it woudl work.

Code:

---

// typedef unsigned __int64 PrimeType;
 
#define PrimeType unsigned __int64

---

Quote:

---

Originally Posted by abachler

well, the actual contest is to generate primes greater than 2^32.

---

Right, I misread the rubric. Looks like you still have zero valid entries, heh.

Quote:

---

Originally Posted by laserlight

Looks like you still have zero valid entries, heh.

---

:)

Right.

Quote:

---

Originally Posted by laserlight

Right, I misread the rubric. Looks like you still have zero valid entries, heh.

---

yeah, I just made the req'd numbers large enough that it was non-trivial to test for primality, because there arent that many small prime numbers and I wanted optimizations that only pay off for large primes to have a fighting chance. I am actually going to update my baseline entry to include some of your code. I want to see if pregenerating the possible divisors improves performance over testing a few extra composite divisors.

Quote:

---

Originally Posted by abachler

yeah, I just made the req'd numbers large enough that it was non-trivial to test for primality, because there arent that many small prime numbers and I wanted optimizations that only pay off for large primes to have a fighting chance.

---

Just to see how brute force will fare I modified my entry such that it only generates all the prime factors for all composites less than the 100000th prime larger than 2^32, and it took just under 30 seconds to run on my computer (which is a little less powerful than yours, but not enough :p).

That would definately beat the baseline, which takes 143 seconds using all odd factors less than the root. The assumption of course is that checking compsite odd numbers is completely worthless because if the number being tested where divisible by a composite, then it woudl be divisible by a prime smaller than that composite which has already been checked. So the actual check of the composite itself does nothing but waste compute cycles. Especially for larger primes where the majority of composite numbers are proven composite in fewer than 256 calculations (a naive assumption) but primes take over 32768 calculatons, so reducing the workload for verifying that a prime is in fact prime will have a significant impact on total throughput.

I made a simple one for under 2^32 which finishes in 132 seconds. Over 2^32 requires some thinking though.

Edit: Oh wait! When I used square root (dumb of me to forget that) I got 100,000 under 2^32 in 0.7sec and 1,000,000 under 2^32 in 18sec. Still no help when doing over 2^32 though.

Well, generating a list of primes less than the maximum root you expect to encounter should allow for an optimized check of the numbers larger than 2^32 as laserlight and i discussed. I am currently adding LL's code to my own to increase the speed of the base algorithm, which should allow for faster throughput.

My submission. Takes 3.8 seconds on my system.

Quote:

---

Originally Posted by brewbuck

My submission. Takes 3.8 seconds on my system.

---

It doesnt compile, rand() apparently isnt defined in cmath, so ill include it and also, typedefing __int64 to bignum doesnt work, as the test program expects the actual function declaration to be PrimeFunc(__int64*), not PrimeFunc(BigNum*); ill fix that as well.

Quote:

---

Originally Posted by abachler

It doesnt compile, rand() apparently isnt defined in cmath, so ill include it and also, typedefing __int64 to bignum doesnt work, as the test program expects the actual function declaration to be PrimeFunc(__int64*), not PrimeFunc(BigNum*); ill fix that as well.

---

Okie dokie.

process terminated after 15 minutes, no results returned...

the only changes I made to your code are -

Code:

---

#include <math.h>
#include <stdlib.h>

//typedef __int64 Bignum;
#define Bignum __int64

---

I am assuming you are doing somethign that implicitly requires the actual bignum type, so perhaps you could rewrite your code so it will compile using the following main (modified from your intrnal one.

Code:

---

#ifdef USE_BUILTIN_MAIN
int main()
{
        __int64 output[100000];

        PrimeFunc(output);
        return 0;
}
#endif

---

ok, here is the base code updated to use laserlights routine to generate the divisors, it then specifically uses the divisors to test primality. The original took 146 seconds, this version took 35, 5 times faster, so definately a worthwhile optimization.

Code:

---

#define DWORD unsigned __int32
#define OFFSET 2
extern void laserlight(__int64*);

void abachler(__int64* PrimeList){
    __int64 Prime = 4294967297;
    __int64 Root = 1;
    __int64 PrimeCount = 0;
    __int64 Divisors[100000];
 
    laserlight(Divisors);
 
prime_start:
    while(PrimeCount < 100000){
        Prime += OFFSET;
        while((Prime / Root) > Root) Root++;
        for(DWORD Test = 1;Divisors[Test] <= Root;Test++){ // skips the 2
            if(Prime &#37; Divisors[Test] == 0) goto prime_start;
            }
        PrimeList[PrimeCount] = Prime;
        PrimeCount++;
        }
    return;
    }

---

Quote:

---

Originally Posted by abachler

process terminated after 15 minutes, no results returned...

---

Stupid signed integer math... Try this:

Quote:

---

Originally Posted by brewbuck

Stupid signed integer math... Try this:

---

ahem, PrimeFunc(__int64*) not PrimeFunc(Bignum*), but I went ahead and added this fix

Code:

---

void PrimeFunc(__int64* data){
    PrimeFunc((Bignum*) data);
    return;
    }

---

4.625 seconds, thats impressive, would you explain your method in detail?

Quote:

---

Originally Posted by abachler

ahem, PrimeFunc(__int64*) not PrimeFunc(Bignum*), but I went ahead and added this fix

Code:

---

void PrimeFunc(__int64* data){
    PrimeFunc((Bignum*) data);
    return;
    }

---

---

Bleh. Thanks.

Quote:

---

4.625 seconds, thats impressive, would you explain your method in detail?

---

It's fast because I'm cheating ;)

Quote:

---

Originally Posted by abachler

4.625 seconds, thats impressive, would you explain your method in detail?

---

Impressive? I thought that "a non-optimized test program was run and completed within the alloted time", which sounds even more impressive :o

Can we use CUDA (Compute Unified Device Architecture)?

Otherwise what's the point of saying you have a 8600GT? :(... there's a horse sitting in the stable and I want to play with him! Basically my plan is to adapt brewbuck's code and win :-) the only problem is I need to understand how it works first...

Quote:

---

Originally Posted by zacs7

the only problem is I need to understand how it works first...

---

I think brewbuck implemented Rabin-Miller, which is probabilistic and hence might return results that fail abachler's contest requirements.

What a cheat :-), oh well... just pick one of those values for the test and give him a big fat zero.

Quote:

---

Originally Posted by zacs7

What a cheat :-), oh well... just pick one of those values for the test and give him a big fat zero.

---

Actually, I think that brewbuck can get away with it. The trick is that the contest is not about coming up with the implementation of an algorithm that accurately determines if an integer greater than 2^32 is prime or composite in the shortest possible time. Rather, it is about producing 100000 primes greater than 2^32 in the shortest possible time. As such, as long as there is no unlucky run, brewbuck passes.

In a way, this is similiar to the requirements of cryptographic algorithms that need large primes (say, produce any 2 primes that meet the size requirements, as fast as possible), hence the choice of the same commonly used algorithm is natural, in retrospect.

Quote:

---

Originally Posted by zacs7

Can we use CUDA (Compute Unified Device Architecture)?

---

yes, both CUDA and OpenMP are available. Please specify which of cuda.lib or cudart.lib your submission requires. OpenMP is limited to version 2.0 as thats what 2008 supports.

Quote:

---

Originally Posted by laserlight

I think brewbuck implemented Rabin-Miller, which is probabilistic and hence might return results that fail abachler's contest requirements.

---

ah, i see now, so basically he is using a non-deterministic approach. If a number fails the test it is definately NOT prime (spectacular failure), but if it passes you cant be 100&#37; sure that it IS prime (unconvincing success). This is an acceptable optimization since it could be applied as a definitive test to weed out many strong pseudo primes. It could then be made comprehensive by applying the modified Sieve of Eratosthenes in the base code. So we run the computationally inexpensive test first and only if it fails to prove a number composite do we apply the expensive test. Although I think i will perhaps switch to AKS for the verification routine.

Here's mine. I hope I didn't break any rules; according to the first post I should have only one function, and I have 2 (+main). If it needs any modifications to be accepted let me know.

Runs in 0.3 secs on my comp.

According to my tests it's correct. If it doesn't work for you in any way, I can try again right? :)

Quote:

---

Originally Posted by laserlight

Actually, I think that brewbuck can get away with it. The trick is that the contest is not about coming up with the implementation of an algorithm that accurately determines if an integer greater than 2^32 is prime or composite in the shortest possible time. Rather, it is about producing 100000 primes greater than 2^32 in the shortest possible time. As such, as long as there is no unlucky run, brewbuck passes.

---

I tuned the constant 'k' for performance at the risk of getting bad primes. Then I crossed my fingers and hoped abachler's rand() function didn't suck.

Quote:

---

In a way, this is similiar to the requirements of cryptographic algorithms that need large primes (say, produce any 2 primes that meet the size requirements, as fast as possible), hence the choice of the same commonly used algorithm is natural, in retrospect.

---

This was basically my reasoning. If it's good enough for cryptographic security, it should be good enough here (although in crypto they iterate to a much higher k value)

Quote:

---

Originally Posted by brewbuck

I tuned the constant 'k' for performance at the risk of getting bad primes. Then I crossed my fingers and hoped abachler's rand() function didn't suck.

This was basically my reasoning. If it's good enough for cryptographic security, it should be good enough here (although in crypto they iterate to a much higher k value)

---

Well, its not so much that it is 'good enough' as it's 'the best they have'. Cryptosystems typically use primes that are at least 2^128 and typically as high as 2^2048 and some international banks use primes greater than 4096 bits. I believe there are commercial(restricted) systems available in the 16K bit range. Obviously these primes can never be deterministically proven prime by checking all possible prime factors, at least not with current computers. Generally even if these numbers arent prime, its good enough that they are not trivially factorable.

I think you can actually reduce k further by choosing specific values for

Code:

---

a = {2 , 7, 61 }

---

as those are the only values necessary to witness agaisnt composites below 4759123141

I think Sfel did even better ...

For those who are interested in the method, I used the sieve of eratosthenes in the following way:

1. Figure out a maximum range (hi) such that the interval [lo = 2^31 + 1, hi] contains at least 100 000 primes.
2. Generate prime numbers (using the sieve) up to sqrt(hi)
3. For each of these primes, find its lowest multiple which is >= lo. Starting from that, mark all its multiples which are <= hi as not prime.
4. All the numbers in the interval [lo, hi] that are not marked as not prime are definitely prime.

So basically, the trick is figuring out how to generalize the sieve of eratosthenes to work for any interval [a,b].

The only disadvantage would be the memory used (I think I use about 2 megs for one of the x arrays), so if you were to ask for, say, a million primes, I'd probably have to resort to using bitsets or bitwise operations to lower used memory.

Quote:

---

Originally Posted by Sfel

For those who are interested in the method, I used the sieve of eratosthenes in the following way:

---

That's interesting. I implemented the exact same algorithm as an alternative to my "primes only" trial division adaptation, but my running time was even worse than trial division (I had to forcibly terminate the process). Maybe my implementation has a bug that caused an infinite loop, hmm...

Is it hard to make an algorithm for prime numbers o.O? I know this dude in Gmod who made one using Wire... Didn't look comlicated at all :P
Oh and I guess 1991 is a prime number! Or was it 1993...

Quote:

---

Originally Posted by Akkernight

Is it hard to make an algorithm for prime numbers

---

Not really. It depends on the requirements.

Quote:

---

Originally Posted by Akkernight

I guess 1991 is a prime number! Or was it 1993...

---

1991 = 11 * 181, but 1993 is prime.

so was 2003 and the next one will be 2011, but then so is 18446744073709551557

there is a rather broad line between numerical analysis and numerology.

It was my intention to participate in this challenge, so I whipped up a modified version of the Sieve of Eratosthenes, where one byte represents 8 numbers. However, I have had some trouble making the code work in a specified range, but I haven't taken the time to look at it properly.

It can primes ranging from 1 to 80 million or so in a matter of seconds so far, I'll just have to see if I can get it to work properly.

The smaller numbers (under 2^32) are generally very easy to prove prime or composite. 64 bit numbers are much slower, both because the math takes twice the bandwidth per variable, and because the proofs themselves are more expensive.

Quote:

---

Originally Posted by abachler

The smaller numbers (under 2^32) are generally very easy to prove prime or composite. 64 bit numbers are much slower, both because the math takes twice the bandwidth per variable, and because the proofs themselves are more expensive.

---

Yes, of course, I wasn't trying to say that it would beat the challenge, but that it did at least look somewhat promising. My previous implementation of the sieve of eratosthenes' memory complexity was O(n), where n is the maximum in the range, while this one's is O(n/8) (I am using the O notation correctly, am I not?), and the previous could generate primes under 10 million(Limit due to the heavy memory usage) in 10 or so secs, while the current can do so in .. 3 secs.

I made this probably a year ago or so, and to be honest I can't really be bothered converting it's interface to the specifications. however, it may be of interest: it can easily calculate >200000 primes above 2^32 in less than 0.4 seconds. it compiles on gcc fine, using the unsigned long long type; not sure about visual c++.

run it like: segprime2 minimum_value maximum_value output_file
eg. segprime2 4294967296 4300000000 outfile.txt will generate 227027 primes

http://sirnot.110mb.com/c/?f=segprime2.c

it uses a 'work array' to maximize its range/number size while minimizing memory usage.

>> while this one's is O(n/8) (I am using the O notation correctly, am I not?)

Not exactly. O(n/8) is equivalent to O(n). In big-O notation all constants are ignored. As n increases, an O(n) running time will increase at the same rate as an O(n/8) running time would, which is why they are considered equivalent.

Quote:

---

Originally Posted by Daved

>> while this one's is O(n/8) (I am using the O notation correctly, am I not?)

Not exactly. O(n/8) is equivalent to O(n). In big-O notation all constants are ignored. As n increases, an O(n) running time will increase at the same rate as an O(n/8) running time would, which is why they are considered equivalent.

---

Ah yes, I see. Thank you.

Quote:

---

Originally Posted by Daved

>> while this one's is O(n/8) (I am using the O notation correctly, am I not?)

Not exactly. O(n/8) is equivalent to O(n). In big-O notation all constants are ignored. As n increases, an O(n) running time will increase at the same rate as an O(n/8) running time would, which is why they are considered equivalent.

---

Thats not entirely true, since when comparing two algorithms, O(n/8) would be faster than O(n). In cases where the running times are being compared (which is often) the constants cannot be ignored. Only when it is specifically comparing the complexity to the size n of an arbitrary input can the constants be ignored.

Right, O(n) ~= O(n/8), it's more a case O(n) != O(log2 n) or O(n^2) - if n is 10000, and you divide by 8, you get 1250. Not a huge number, not a small number. O(log2 n) for n=10000 is about 13, O(n^2) is 100000000.

And more importantly, if we double n, O(n) also doubles. O(n^2) is 4x larger, O(log2 n) is one larger.

So the point about big-O is the ability to predict from a small run (low n), how a larger n will behave - this is a bit more difficult in modern machines with caches, virtual memory and other aspects, but we can still predict with some accuracy what will happen if we for example double the amount of data - will the time double or increase more/less than double?

--
Mats

>> Only when it is specifically comparing the complexity to the size n of an arbitrary input can the constants be ignored.

But is that not what big-O notation is intended for? If you want to compare running times (which of course is often a relevant endeavor), you shouldn't be using big-O notation.

Except you arent always comparing actual runnign times, but computational complexity. So one algorithm may solve the problem in O(n log n) time, while another algorithm may solve it in O(n/2 log n) by discarding half the test cases based on some trivially computable feature. e.g. an algorithm that finds all prime numbers between 3 and n > 3 by testing every number, versus the same algorithm that only tests odd numbers between 3 and n > 3.

Quote:

---

Originally Posted by abachler

Except you arent always comparing actual runnign times, but computational complexity. So one algorithm may solve the problem in O(n log n) time, while another algorithm may solve it in O(n/2 log n) by discarding half the test cases based on some trivially computable feature. e.g. an algorithm that finds all prime numbers between 3 and n > 3 by testing every number, versus the same algorithm that only tests odd numbers between 3 and n > 3.

---

Except that by definition O(n/2 log n) == O(n log n). Nobody's saying there's no difference in run time, it's just not right to talk about it using big-O.

If I remember, O(f(x)) = g(x) if there exist constants c, d, and e such that c * f(x) + d >= g(x) for all x > e. Thus, O(n / 8) = O(n), because 8 * (n / 8) + 0 >= n, for all x > 0. (c = 8, d = 0, e = 0)

Quote:

---

Originally Posted by CrazyNorman

If I remember, O(f(x)) = g(x) if there exist constants c, d, and e such that c * f(x) + d >= g(x) for all x > e. Thus, O(n / 8) = O(n), because 8 * (n / 8) + 0 >= n, for all x > 0. (c = 8, d = 0, e = 0)

---

Another way to put it is that lim [n -> infinity] f(n)/g(n) = k where k is some positive constant.

Greetings, folks.
Congrats on the terrific submissions. I can't find who won - or abachler's source test code. Will someone help me out, please?

Thanks!

Sfel, probably.

Nothing like bumping a year old thread.

I know, but the code's still good :)
Can anyone hook me up? Trying to do a primality program for school on the GPU and I'm currently not winning...

Thanks!

Quote:

---

Originally Posted by deluge01

I know, but the code's still good :)
Can anyone hook me up? Trying to do a primality program for school on the GPU and I'm currently not winning...

Thanks!

---

What do you mean by "hook me up"? Are you not able to download the attachments in this thread?

Quote:

---

The rule is to prevent someone from just writing a huge array with all the values and returnign it.

---

amday i was going to do that.


you said

Quote:

---

here is an example of one possible solution.

---

since no one has entered something like that i will. let see what it do.