Tetrium wrote:

Frankly, I have no idea how to make nice little graphs, but it could help make it easier to compare results.

Consider downloading the free Open Office organisation software suite. In it, you'll find a spreadsheet. Using it, you can turn the data in to a bar chart graphic. You'll then need to convert this graphic in to a picture, for uploading to Vogons for example. I'm not sure the best of way of doing this. In the past, I've used a screen capture program to "grab" the bar chart graphic from a spreadsheet in order to convert this image to an uploadable picture.

What about Google Chart Tools?

I just put some graph together quick'n dirty from your results in the first posting:

If you want to take this as start, it was done with Igor pro / Wavemetrics. I could send you the file for it, with some additional explanation.

Thats a good start. I've just come back and am too tired to do anything serious. I'll look into it tomorrow.

Perhaps it's an idea to atleast make graphs with all cpu's from 1 family (say, all socket 3's together, including POD's).
Also the used chipsets will have an effect on performance. Even though I only tested 2 P3's on a VIA chipset, so far VIA P3 chipsets seem to have lesser performance then the Intel chipsets.
If we put all results into a single graph and add more later, things could get really messy 😜

Intel Celeron III 1.2 GHz @ 1.35 GHz (113 MHz FSB), Shuttle AV18, 768 Mb PC133 SDRAM @ PC146, Windows 2000 Professional SP4:
0h 00m 24.646s [256k]
0h 02m 10.368s [1M]
0h 10m 56.895s [4M]

Intel Core 2 Duo E7400 2.8 GHz, ASUS P5KPL/1600, 4096 Mb DDR2-800, Windows 7 Professional:
0h 00m 03.485s [256k]
0h 00m 19.156s [1M]
0h 01m 47.703s [4M]

Svenne wrote:

Intel Celeron III 1.2 GHz @ 1.35 GHz (113 MHz FSB), Shuttle AV18, 768 Mb PC133 SDRAM @ PC146, Windows 2000 Professional SP4: 0h […]
Show full quote

Intel Celeron III 1.2 GHz @ 1.35 GHz (113 MHz FSB), Shuttle AV18, 768 Mb PC133 SDRAM @ PC146, Windows 2000 Professional SP4:
0h 00m 24.646s [256k]
0h 02m 10.368s [1M]
0h 10m 56.895s [4M]

Intel Core 2 Duo E7400 2.8 GHz, ASUS P5KPL/1600, 4096 Mb DDR2-800, Windows 7 Professional:
0h 00m 03.485s [256k]
0h 00m 19.156s [1M]
0h 01m 47.703s [4M]

Could you run the celeron at it's stock speed also (and fsb 133 if your chip can make the overclock). Did you use a tualatin adapter on your board?

And thanks for posting! 😉

Edit: I came up with an idea for the graphs. How bout we use different colors for different chipsets used? For instance, make the results from VIA boards green and Intel red?
VIA P3 chipsets seem to be around 10% slower for any given cpu.

Maybe this is interesting. I used DosBox to log 1000000 cycles after I started a 256 K calc. It does not converge in DosBox, so I guess there is some emulation problem still, BUT it runs until the error comes up. So i guess the code represents the same code as if it would run right.

Only commands within the SuperPi process were taken into account:

Command / count
add 1598500
and 906075
call 4001
cmp 33673
dec 47
enter 71961
fabs 286
fadd 2734
faddq 1146
fdivp 2135
fild 3845
fld 9295
fldq 34735
fmul 4192
fmulq 12710
fstp 860
fstpq 65372
fstq 12600
fsub 1508
fsubq 13148
fsubrq 8
fxam 405
fxch 23598
imul 13
inc 1563
jbe 491835
jc 598848
jle 1092
jmp 757
jnc 481
jne 2043
jpe 74576
lea 5255
leave 32
lsl 1019
lss 19
mov 412311
movzx 14
not 32
or 1037
pop 703926
push 56556
repe 53
repne 35
ret 580
sahf 1202710
sar 7
setge 904772
shl 2
shr 5
sub 12
test 2407
xor 9

sum of commands executed: 7264831
FPU commands: 188577
FPU part: 2.6 %

Well I would like to have an emulation so that SuperPi runs correctly and maybe some kind of live logging in DosBox?
Is there a way to stream a permanent logging to another application for live statistics?

I reread a couple times what you wrote eliandra. Am I correct when I assume that you tested the 'buggy' version in Doxbox and it made a full calculation until that bug happened? Or am I shooting in the wrong direction here?

On another note, as I have no idea what the best way is to displaying the results I just put everything in one big list from fastest to slowest and start analyzing from there.

Has anyone here ever managed to get windows 3 bootable from a floppy? It would be very handy if I could test superpi that way.

I haven't actually done a lot of hardware thingies lately because of the heat here in The Netherlands

I reread a couple times what you wrote eliandra. Am I correct when I assume that you tested the 'buggy' version in Doxbox and it made a full calculation until that bug happened? Or am I shooting in the wrong direction here?

Well, its a bit different. I used SuperPi in DosBox 0.74.
SuperPi calculates for some time (probably the first iteration) and then complains that some result is not right. (the iteration does not converge, but it should)
So SuperPi works fine, but the DosBox Emulation seems to be imperfect with some FPU commands.
What I did is, let the calculation of a 256 K digit number of Pi run for an equivalent of 1000000 Dosbox cycles. You know there is first the window, where you have to press 'ok' that the calculation starts. There I paused Dosbox started the log (log 1000000) and immidiatly switched back into the emulation and chose 'ok'. Since emulation slows down with log considerably anyway, the error due to the short wait for ok at the beginning is minimal. Also only commands running in the memory area of the SuperPi process were evaluated.

So what the numbers mean: Within the virtual timeframe of an equivalent of 1000000 DosBox cycles the emulation executed 7264831 commands in the SuperPi process.
1598500 of this commands were 'add' (neglecting the different operands), 906075 were 'and' and so on. I made a short program that counts all commands executed there consequtivly from different memory locations.

If the way of calculation in SuperPi does not change considerably later, the snapshot of the 7264831 commands executed could be representative. So 2.6% of the commands executed may be FPU commands. This does say nothing about the time they take on a 386 f.e.
Evaluating this would be a bit more complex, since I would have to take a table of how many cycles a certain command with a certain addressing mode takes (f.e. for cache hits) and add this up. Stlll this would be just a raw estimation.

If Dosbox will work perfectly somewhere in the future and SuperPi runs until the end then a feature where you could start logging until a certain memory address in execution is reached. Then you could log a complete run of maybe a 64 K calculation and do statistics.
Oh and you would wonder, how old code differs from code nowadays...

Would it be possible to write 'a superpi' that'll work from DOS?

Well what do you want exactly?

SuperPi ist an implementation of the Gauss Legendre algorithm. So you could just take a DOS programming IDE and write such an implementation.

If you want the identical (or at least compareable) code used in SuperPi you have to kick all windows specific functions and redo it yourself. This might not be too complicated if you use f.e. Watcom C with DOS4GW-Extender. Then you copy the calculation routine to the new framework.

Though while this is possible with enough effort it is still questionable what you gain.

Nice and compareable benchmarks are available as source. Like Dhry- and Whetstone Routines (f.e. on Roy Longbottoms site). So you can compare from old VAX-Stations to new x86. And you also can compare different compilers/optimizations and instruction sets.
The point with this is, that f.e. SuperPi is closed source and basically 386 Code with FPU usage. How compareable is this on f.e. 64 bit Core2 architecture?
If you would have the source, use a modern compiler, the additional registers in 64 bit mode and SSE4.1 it would have a new dimension of performance - still giving the identical results.

So the closed source binary is very special and has on modern CPUs not much real world value. Maybe it says how nice these CPUs can execute old 386 code.

Sorry, still no superpi results from my 486, this machine acts a bit weird lately. Symptoms include random crashes, strange sounds from the AWE32, failing network connections and palette errors on VGA. But I promise to post scores once my 486 works again.

Sorry Elianda, but I don't have an IQ of 200+ 😜
I did a little java years ago but I found out programming is definately not one of my better talents.

And about my choice of superpi, so far it's the most versatile cpu benchmark program I've found and used so far.

I just like to see what others are getting from their systems, it's fun! 😀

@5u3: Any idea what the problem is? Better not be a dying motherboard...

SuperPi on Asus 486 mobo PVI-486SP3 (Rev 1.8, 0306 BIOS, Maxed out BIOS settings), Intel DX/4-100 WB enhanced, 32Mb FPM, Windows 98 SE.

16K = 24.280 seconds
64K = 2 minutes and 05.315 seconds
256K = 11 minutes and 25.570 seconds
1M = 56 minutes and 01.016 seconds. Score = 297.5290

I've run two SuperPi tests on the same mobo, with the same CPU. Test #1 used a Pentium MMX 233MHz, and for test #2, the mobo's FSB was overclocked to 100 FSB (from 66) so that the P-MMX-233 CPU was overclocked to 300MHz. I wanted to see if this overclocked mobo/CPU system was stable, and it does seem to be. The mobo is a Diamond Flower P5BV3+, with the VIA MVP chipset.

This image shows SuperPi (top left), and Sandra 2002 Pro with the CPU speed, FSB, and CPU temp. Nothing has been overclocked.

This image shows the same apps as above. The system has been overclocked to 100 FSB, so that the CPU is running at 300MHz.

The CPU temp readings are interesting. To see this "dark voodoo" project in action, you can read about it here. (Scroll to bottom of page.) For the SuperPi tests above, I removed the tin of paint and cartons of juice. After the overclock testing was complete, I powered down the system, and then felt the heatsink with my fingers. I could not sense any heat on this large copper heatsink. BTW, the VCore was set to 3.2 (from 2.8 ).