[Licht]

Welcome to the most posted in topic in coding and programming!

After much work and allot of delays and errors i have finally finished build 3.

8, 30th : Next version is version 1. Stress testing is near finished and has been released to testers, proven to be highly effective and efficient. All glitches from last version are already fixed. Next version is from scratch so it'll be a lot cleaner, way different. Drawback being it takes a while to recode everything.

http://www.overclock.net/downloads/3...ml#post3674602

 

[Duckydude]

Nice work

, worked perfectly for me

. This sounds like a really cool project, would be a nice new benchmarking utility that we could compare around here.

Here are my results for 25K:

 

[Licht]

Quote:

Originally Posted by Duckydude Nice work , worked perfectly for me . This sounds like a really cool project, would be a nice new benchmarking utility that we could compare around here. Here are my results for 25K:

I'm working on build 3 for you Q6600 guys, will be done very soon. Should support the full 16 cores. (I will have to do a bit of math before anything so i can optimize it.)

 

[dskina]

Running at stock everything, atm.

 

[Licht]

Quote:

Originally Posted by dskina Running at stock everything, atm.

I don't think B2 counts prime numbers incorrectly (cross thread integer changed must throw it off.)

 

[The Bartender Paradox]

A question and a suggestion-

What method are you using to check for primes?

Also perhaps you could include some info on how many prime numbers there are for our given length chosen, or spit out an error when the number of primes found don't match the number of primes there actually is. So we can see if our computer screwed up calculating.

Oh, and a B2 screeney: (stock Q6600)

Edit: err.. compare this to Duckydude, I found 2 more primes

 

[Licht]

Quote:

Originally Posted by The Bartender Paradox A question and a suggestion- What method are you using to check for primes? Also perhaps you could include some info on how many prime numbers there are for our given length chosen, or spit out an error when the number of primes found don't match the number of primes there actually is. So we can see if our computer screwed up calculating. Oh, and a B2 screeney: (stock Q6600) Edit: err.. compare this to Duckydude, I found 2 more primes

Yeah i already confirmed that it was counting prime numbers wrong. It has something to do with cross thread value accessing. It is an easy fix and will be resolved in build 3. My method for detecting prime numbers is a simple and efficient method, however i am keeping it a secret until V1.0 when i go open source. (Unless plans change, although i promise to give that code up on V1.0 regardless, it is done in a single line of code!) Also, yeah i am also working on a sum check for Build 3 or 4.

Thanks for the help man, based on your noticing the 2 number difference in detected primes i can now confirm the error is within the crossthread memory access. I will find a way around it in build 3, shouldn't be too hard.

Ok, long story short. Memory access is bugged, working on the issue be done soon. All scores are indeed valid the error is in the memory not in the system itself, i personally guarantee all scores are 100% accurate up to a 10th (It is impossible on Windows to measure a length of time more precise then this) of a second (the score variances between tests are caused by other threads interfering with my applications processing, the more programs you turn off the less it will vary. If i forbid this it could cause system instability, this issue is present in every benchmark.)

 

[ThePope]

Sweet Licht! I Cannot wait to see more of your work

 

[Polska]

Cool stuff will keep an eye on this. Here is one result of mine. This is on stock e6850 (having system stability issues trying to determine if its to do with overclocking

).

Also, after I ran a test, the radio buttons for the number of threads all became accessible (screenshot 2).

I don't know if you detect how many cores the system has (because mine only had 1 and 2 available on program launch) but once they were available I ran it with 4 threads (on a dual core) and the program crashed. I assume you want the other options disabled, just wanted to let you know they are available after running the benchmark once.

 

[Licht]

Quote:

Originally Posted by Polska Cool stuff will keep an eye on this. Here is one result of mine. This is on stock e6850 (having system stability issues trying to determine if its to do with overclocking ). Also, after I ran a test, the radio buttons for the number of threads all became accessible (screenshot 2). I don't know if you detect how many cores the system has (because mine only had 1 and 2 available on program launch) but once they were available I ran it with 4 threads (on a dual core) and the program crashed. I assume you want the other options, just wanted to let you know they are available after running the benchmark once.

I had forgotten about that hickup, it came after i ran into some autoscaling issues with my adaptive threading. I meant to lock them off but apparently overlooked that before releasing (i was rushing quite a bit.) Now i am working on finishing up my adaptive threading code, when i am done it will be capable of any amount of threads no matter the number without losing any performance. This was intended for build 2 like i said but the rush left me locking the controls then forgetting to remove said renabling code.

No, i am not detecting how many cores the system has right now since that could leave the program locking off controls for rigs in the future when CPU access may be changed. Since you can run any amount of threads on any CPU it doesn't matter, so i classified those controls as thread controls instead of core usage controls. Although you can run 16 threads on a dual core for example, you will get better performance with 2.

PS : Just realized something, don't touch more threads then you have cores. The way i have thread affinity set up for adaptive threading will crash it after all...

 

[Kamakazi]

1st of all this is cool.

Second of all, where do I get the rad megaman background?

 

[afzsom]

Using build 2, here are the computer specs:
E6600 @ 3.6GHz (1.425v, 400x9)
DDR2-800 Corsair XMS2 (5-5-5-12 2T)
Windows XP Pro SP2 32bit

 

[Polska]

Quote:

Originally Posted by Kamakazi Second of all, where do I get the rad megaman background?

It's actually part of a larger background I whipped up quickly from something I came across on digg. (It's made so it looks like they are standing on the taskbar

)
http://polska.laggers.ca/img/bg.jpg

Here without the Polska text if you wish to use it.
http://polska.laggers.ca/img/nsbg.jpg

The psd (photoshop) if you want to totally change it:
http://polska.laggers.ca/img/sbg.zip

EDIT: sorry for taking it off topic.

 

[Licht]

Quote:

Originally Posted by Polska It's actually part of a larger background I whipped up quickly from something I came across on digg. (It's made so it looks like they are standing on the taskbar ) http://polska.laggers.ca/img/bg.jpg Here without the Polska text if you wish to use it. http://polska.laggers.ca/img/nsbg.jpg The psd (photoshop) if you want to totally change it: http://polska.laggers.ca/img/sbg.zip EDIT: sorry for taking it off topic.

I don't care. Go as offtopic as you like.

 

[C-bro]

Just figured I'd let you know that I came across the same issue with the run once and unlock all 16 threads. But another error I have found is if you run a lengthy benchmark and close the application (with the X), it continues to run in the background. I had originally tested with 75k and I shut it down, then like 5 minutes later I had the result pop up. You may want to add a "Shutdown" button that uses Application.Exit(). I believe that not only stops all threads but also frees resources when working with C#. It's the way to properly close a program from a button.

 

[LoGGi!]

I found no other glitches than the one that makes you able to choose any amount of threads. Seems cool though, ran it in 18453 with my 6400+ at 3512 MHz. Seems the AMD's keep up a bit better compared to the Intels in Prime than Pi

 

[Dueling Banjo's]

couldnt u just run multiple instances of super pi?

 

[Licht]

Quote:

Originally Posted by Dueling Banjo's couldnt u just run multiple instances of super pi?

This is finding prime numbers, not calculating the value of pi, which is different. Ontop of that running 2 instances of superpi requires you to set affinity for each one. And ontop of that you couldn't get an accurate score off of it. It also makes it impossible for the cores to work together, this program is far superior to super pi (or will be upon completion) in measuring the power of multi-core CPU.

Quote:

Just figured I'd let you know that I came across the same issue with the run once and unlock all 16 threads. But another error I have found is if you run a lengthy benchmark and close the application (with the X), it continues to run in the background. I had originally tested with 75k and I shut it down, then like 5 minutes later I had the result pop up. You may want to add a "Shutdown" button that uses Application.Exit(). I believe that not only stops all threads but also frees resources when working with C#. It's the way to properly close a program from a button.

Yeah i am working on that, i need to access the close application button event. I also need to lock the maximize button. I have the access any number of threads fixed, and i'm pretty sure i have all 16 threads working. Releasing the next build with all this plus the stuff i didn't mention after i fix a few things.

Quote:

I found no other glitches than the one that makes you able to choose any amount of threads. Seems cool though, ran it in 18453 with my 6400+ at 3512 MHz. Seems the AMD's keep up a bit better compared to the Intels in Prime than Pi

Any program that allows the cores to work together will allow the CPU to use it's HT links, thus giving AMD a slight advantage. I am also considering parallel processing to further increase multi-core utilization. Which would at the same time give AMD even more of an advantage (any program that uses multi-core well gives AMD an advantage, it is just what comes with good multi-core programming and HT links. That also means Nahalem will gain advantages, any CPU with HT links will.)

\\/ \\/ \\/
Ok long story short, the bugs in Build2 are fixed and Build3's bugs simply need to be corrected then i am done.

 

[LoGGi!]

Nice, keep up the work

 

[Licht]

Well, i am stuck. Anyone with knowledge of C# they think is greater then mine please add me on a messenger i need assistance correcting 2 issues. Details upon adding me.