|
-
May 11th, 2012, 03:03 PM
#1
Running on 8 Cores?
I made a program which finds the prime numbers from 0 to 100 million, and ran it on my laptop (core 2 duo, 1.83ghz, 2gb ram).
It takes around 35 seconds for it to sieve all the non-prime numbers on my laptop.
I then ran the same program on a windows server, 2x 64 bit Intel Xeon Quad Core Processors @ 1.6 ghz, 6gb ram, and it takes the same amount of time, even when I set the priority to high and the affinity to all 8 cores, it seems to only use one core for the processing, is there any way to make it use all 8 cores at close to 100%?
I really want to see how fast I can get this program up to!
Cheers,
-Sam
-
May 11th, 2012, 03:46 PM
#2
Re: Running on 8 Cores?
Victor Nijegorodov
-
May 11th, 2012, 03:47 PM
#3
Re: Running on 8 Cores?
>> I made a program ...
Did you create any threads in your program?
gg
-
May 11th, 2012, 07:15 PM
#4
Re: Running on 8 Cores?
 Originally Posted by Codeplug
>> I made a program ...
Did you create any threads in your program?
gg
I looked into multithreading but it looked far too complicated for my to tackle right now, I've only been learning C++ for about 1 week.
Unless there is an easier way of creating threads?
-
May 11th, 2012, 10:03 PM
#5
Re: Running on 8 Cores?
Creating threads is not difficult at all, it takes only a few lines of code - find some samples. Parallelizing your code to run on those threads would be challenging - google for it, I bet you'll find some answers on how to parallelize finding primes algorithm.
-
May 12th, 2012, 04:45 AM
#6
Re: Running on 8 Cores?
 Originally Posted by SamstaUK
I really want to see how fast I can get this program up to!
Theoretically the 8-core version can run 8 times faster than the 1-core version. In practice it will be somewhat slower due to overhead but you should be able to get at least within 90% of maximum performance. But first you need to accomplish two things; You need to come up with a parallellized version of the prime number algorithm, and you need to ensure all 8 cores are kept buzy at all times.
For the second part I recommend the task based approach represented by say the TBB package,
http://threadingbuildingblocks.org/
Rewarping oneself from sequential to parallell thinking requires some effort but it's a worthwile investement for the future.
Last edited by nuzzle; May 12th, 2012 at 06:53 AM.
-
May 12th, 2012, 10:43 AM
#7
Re: Running on 8 Cores?
If you find running multiple threads is too complicated, you can always look into running two independent program instances first...
For example one could find all the primes between 1-5000, while the other finds all the primes between 5001-10000.
Is your question related to IO?
Read this C++ FAQ article at parashift by Marshall Cline. In particular points 1-6.
It will explain how to correctly deal with IO, how to validate input, and why you shouldn't count on "while(!in.eof())". And it always makes for excellent reading.
-
May 12th, 2012, 02:01 PM
#8
Re: Running on 8 Cores?
I agree with nuzzle, as using Intel TBB has certainly more advantages than managing threads yourself.
For prime numbers, you can take a look at the example provided for parallel_reduce.
-
May 14th, 2012, 08:01 AM
#9
Re: Running on 8 Cores?
You have to create threads to use multiple core. A good rule of thumb is however many cores you have, you should have double the number of threads. That rule starts degrading as the number of cores climbs, but for 8 core, 16 threads should still be close to optimal.
-
May 14th, 2012, 11:00 AM
#10
Re: Running on 8 Cores?
 Originally Posted by ninja9578
You have to create threads to use multiple core. A good rule of thumb is however many cores you have, you should have double the number of threads. That rule starts degrading as the number of cores climbs, but for 8 core, 16 threads should still be close to optimal.
Who's rule of thumb is that? AFAIK, the ideal is to have as many threads as there are processor cores available to the program and then try to minimize synchronization. If you have more active (i.e. not waiting) threads than processor cores, you will likely get more context switches, which does not help performance.
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
-
May 14th, 2012, 04:52 PM
#11
Re: Running on 8 Cores?
 Originally Posted by SamstaUK
I made a program which finds the prime numbers from 0 to 100 million, and ran it on my laptop (core 2 duo, 1.83ghz, 2gb ram).
It takes around 35 seconds for it to sieve all the non-prime numbers on my laptop.
What exactly are you timing?
I am not sure I did it right, but I found 5,725,359 prime numbers in under 2.5 seconds.
Not sure how to verify it, but the last number is 99,999,989.
Can you please match it with your results?
If I got it right – I don’t know what are you doing for 35 seconds.
However, I was not able to output those numbers (just don’t have patience to wait for it); it does take a LOT of time, way more than 35 seconds.
My point is – before getting into multithreading, make sure that you use a good algorithm and that you implement it correctly.
<Added>
Ran this thing to completion, with printf() for each prime number found.
It took 548 seconds (over 9 minutes)!
Last edited by VladimirF; May 14th, 2012 at 05:04 PM.
Reason: Added printf timing
Vlad - MS MVP [2007 - 2012] - www.FeinSoftware.com
Convenience and productivity tools for Microsoft Visual Studio:
FeinWindows - replacement windows manager for Visual Studio, and more...
-
May 15th, 2012, 04:01 AM
#12
Re: Running on 8 Cores?
 Originally Posted by VladimirF
My point is – before getting into multithreading, make sure that you use a good algorithm and that you implement it correctly
The problem is that the good serial algorithm you've meticulously implemented then seldom is easy to parallelize. The much better and recommended approach is to design for parallelism from the ground up.
If you start with a serial design and then try to parallelize it you almost always end up with mutexes all over the place and threads that spend lots of time waiting. If you think parallel from the start and use a task based approach (ala TBB) you can often achieve a lock-free design with much better core utilization that also scales much better when more cores become available.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|