Super PI with msec/anticheat mod

[alexio]

Where can I get the source for super pi?, I've been looking for it for a while now.

[snq]

There is no source. This mod was done with a hex editor and some asm tools.

No, I'm not kidding

[alexio]

There is no source. This mod was done with a hex editor and some asm tools.

No, I'm not kidding

Very nice, that must have been quite allot of work then.

Do you have the exact formula for calculating Pi in a text file that I can just copy->past, the method that Super Pi uses to calculate PI that is.

I might want to build a new program from the ground but I'm not so good in mathematics that I can just convert a formula in a way a C++ compiler understands.

On the other hand, Super PI is actually a peace of crap if you look at the time it takes to calculate Pi.

Ofcourse I understand that it has become a standard in benchmarking, but wouldn't it be nice if there was a more efficient program for calculating PI?

QuickPi for example calculates PI far faster than Super Pi but I just don't like the program. So wouldn't it be nice if I could just implement the formula of quickPI in Super Pi and make the program allot faster wile keeping the nice layout.

I might email the author of super PI and ask for the source, does anyone has his email?

[Andrewv]

nice mod but it sux :\

Not modded: 48sec
Modded: 49.375sec

[snq]

nice mod but it sux :\

Not modded: 48sec
Modded: 49.375sec

Try running it a couple of times more. Most likely the 48sec was a high 48 and your cpu got occupied with something else while running the modded one. 0.4 secs difference isn't the whole world, just do a few more runs with both

[snq]

Sorry, I don't have that. I guess with a lot of time and effort it would be possible to rip out all the necessary code but it's nearly impossible. For example all addresses used would need to be changed, not quite a fun task.. It would be a lot easier to take some opensource PI code and use that. There's lots of code available but as SuperPI is kind of the standard when it comes to PI benching I just added some features that were missing

The latest superpi version was released about 10 years ago (august 95) so even the original author might not have the source any more.
Anyway on http://pi2.cc.u-tokyo.ac.jp/ you can find some more info.

[snq]

That's good to hear

So.. does anyone have any more ideas for new features? I'm kinda bored

[scsim]

Hi! I am facing some strange issues. When I OC my P4 3.0E to 4.3GHz, Super PI will post crazy results. At 4.289GHz, my result is 31.562sec. When I bump my FSB 1 MHz higher, the results became 1hr 51min. Of course, it doesn't take that long to complete (slightly more than 30sec). Just that the time shown for each iteration is wrong.

I used to face this issue when WinXP couldn't detect anything more than 4.3GHz problerly. SP2 seems to solve that problem but it appears that no all programs are working. Any work around?

Thanks!

[bachus_anonym]

@snq

I've just seen some CRAAAZZYYY time in SuperPi 16M with the latest MOD. Checksum turnes out OK Something that might be similar to above post... Just look for yourself, bud:

11:30 - P4 3.0EGHz @4501MHz (15x300)

09:06 - P4 530 3GHz @ 3890MHz (15x259)

The author of that first score says that he was not cheating and numerous runs show pretty much same results...

Something must be wrong with that MOD. Can you take a look at it, please ?

[vanovich]

Hi! I am facing some strange issues. When I OC my P4 3.0E to 4.3GHz, Super PI will post crazy results. At 4.289GHz, my result is 31.562sec. When I bump my FSB 1 MHz higher, the results became 1hr 51min. Of course, it doesn't take that long to complete (slightly more than 30sec). Just that the time shown for each iteration is wrong.

I used to face this issue when WinXP couldn't detect anything more than 4.3GHz problerly. SP2 seems to solve that problem but it appears that no all programs are working. Any work around?

Thanks!

if your cpu is a bit unstable ,one can get funny results . i got 23000 in sissandra drystone when i ran at 4.800mhz

[snq]

Hmm.. that's odd.
An explanation could be that your timers are off at such high clocks. I still use windows timing functions in this version, but I believe this timer relies on clock speed and afaik it's calibrated at boot time. Now I'm not sure exactly how this is done but it could be that sometimes (?) the timer is not recalibrated when you change the clockspeed using clockgen or some other tool?
Obviously it's a problem tho, I'll see what I can do about it! I just hope I don't have to fall back on the old 15-msec-jump-timing :/

[bachus_anonym]

Hmm.. that's odd.
An explanation could be that your timers are off at such high clocks. I still use windows timing functions in this version, but I believe this timer relies on clock speed and afaik it's calibrated at boot time. Now I'm not sure exactly how this is done but it could be that sometimes (?) the timer is not recalibrated when you change the clockspeed using clockgen or some other tool?
Obviously it's a problem tho, I'll see what I can do about it! I just hope I don't have to fall back on the old 15-msec-jump-timing :/

Well, this person says that with Original SuperPI he gets around 14:00, which is about right... So you might wanna try to poke around and see what could be the problem.... And I think so far this happened only on Intel / Prescott...

[snq]

The problem is I changed the function used to get the time, so the problem has to be there. This is really bad news because I really loved this new function without the weird jumps. But if it's acting like this it will have to go

Unfortunately I don't have a prescott to test with but I will try starting with a heavily underclocked system and throw up the FSB while in windows, that should show me if this function adjusts properly or not.

[snq]

I don't know anything about clocking Intel CPUs but do those things support HT and if so do you have it enabled?

If so that could be causing the problem.

On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL). To specify processor affinity for a thread, use the SetThreadAffinityMask function.

[snq]

Can you guys test this one?
It has the old timing functions, still msecs but with small jumps. I guess for calculating 16M/32M 15 msecs more or less wont be a big deal

[Sucka]

Good work on the PI updates. Now once everyone can use SSE3 we won't have anything to complain about :p

[bachus_anonym]

thanks snq,

I posted this information along with a new link on my native forums... I will let you know how it worked out

[snq]

ArcTan, that's what I was afraid of. The timer is not reinitialized
Try this one: http://superpi.radeonx.com/super_pi_mod-1.4.zip

[ArcTan]

thanks
works now

[Sons_of_Piru]

impresive reverse engineering work, good job

[snq]

Thanks Sons of Piru

[kiko]

same settings. :/





Ciao

[detonator]

same the guys abouve, my ptime is still 0.500msm differetn from the originall....
anti cheat=35.629
originall=35.140....
inprouved but still wrong

[wwwww]

same settings. :/





Ciao

why doesnt it say the cpuz checksum? i have that prob on my dothan as well and on 6** cpus.

well heres my score



dothy 745 @ 2.78Ghz (173*16) 1.68V (shoddy filo chip)
mushy black @ 288MHz 2-2-2-5; 4.1V
the dfi 855 board

[TEDY]

what is NOT EXACT IN ROUND ?

280*9....prime stable and superpi not ?

works now with 1.4