SysInfo 4.0

[gulliver]

Originally Posted by cylon

autoconfig support & boardslib detection would be more useful. ;-)

+1

[Geijer]

Originally Posted by Cylon

AutoConfig support & Boardslib detection would be more useful. ;-)

Yes, AutoConfig is definitely preferable!

[bubbob42]

Any progress with BoardsLib & SysInfo?

Sorry, had to ask

[Geijer]

Originally Posted by bubbob42

Any progress with BoardsLib & SysInfo?

Sorry, had to ask

A redesign of the Boards page is quite high on the todo list to handle longer names to be able to use the results of BoardsLib.

[kolla]

4.0 only sees 1MB of "slow ram" on the Minimig, instead of 1.5MB that is available. I can dig out screenshots and more memory addresses later

[Geijer]

Originally Posted by kolla

4.0 only sees 1MB of "slow ram" on the Minimig, instead of 1.5MB that is available. I can dig out screenshots and more memory addresses later

Thanks, will look into that.

[eXeler0]

@Geijer , is there any chance at all you would look into the MIPS benchmark code when running on superscalar CPUs so that it more accurately measures the performance of CPUs capable of executing 2 or more instructions in parallel?
(So basically, the 060 and the Apollo-core).

(Not sure what compiler you're using btw..)

Other (better?) ideas? Maybe add a "productivity" test such as "archiving a file" or similar?



Skickat från min HTC One via Tapatalk

[Cylon]

Once you call a test result "Dhrystone" or "MIPS" you certainly have to stick to some algorithmic rules, otherwise it would just return "bogusmips" or whatever.

[eXeler0]

Originally Posted by Cylon

Once you call a test result "Dhrystone" or "MIPS" you certainly have to stick to some algorithmic rules, otherwise it would just return "bogusmips" or whatever.

Yes, but a CPU that can execute 2 instructions per clock cycle is not measured fairly if the MIPS are for code running on only one pipeline.
Theoretically, a 50MHz 060 could have 100MIPS if we toy with the idea that every instruction can be executed in one cycle. But only if both pipelines are fully fed.

Skickat från min HTC One via Tapatalk

[Cylon]

Yes, fairly enough. But the speed rating and drive speed results are qualified for a pit stop alltogether. Major overhaul, imho.

[eXeler0]

Originally Posted by Cylon

Yes, fairly enough. But the speed rating and drive speed results are qualified for a pit stop alltogether. Major overhaul, imho.

You might have a point here, maybe SysInfo is a bit too old altogether to be fixable into something really useful on for e.g. the Vampire.

Skickat från min HTC One via Tapatalk

[matthey]

Originally Posted by eXeler0

Yes, but a CPU that can execute 2 instructions per clock cycle is not measured fairly if the MIPS are for code running on only one pipeline.
Theoretically, a 50MHz 060 could have 100MIPS if we toy with the idea that every instruction can be executed in one cycle. But only if both pipelines are fully fed.

Dhrystone MIPS are measured with some fairly simple C algorithms. Compilers can produce optimal code for superscalar processors like the 68060 and Apollo core but they generally don't for the 68k. Dhrystone MIPS ends up measuring the compiler optimization capabilities. The compiled code can be hand tweaked following the rules for Dhrystone which makes a huge difference but some would say that is cheating. Using the Dhrystone MIPS algorithm makes sense but then the decision of which resulting executable to use is not so simple. Of course anything would be better than the old SysInfo speed test which doesn't even use common instructions.

[Cylon]

I doubt the assembler used to compile SysInfo does anything specific regarding 040/060 behaviour. That's why it returns bogus results, even if the factor of speed increase is plausible.

[matthey]

Originally Posted by Cylon

I doubt the assembler used to compile SysInfo does anything specific regarding 040/060 behaviour. That's why it returns bogus results, even if the factor of speed increase is plausible.

An assembler programmer has to do his own instruction scheduling and choose the instructions which work in all integer pipes. A compiler is supposed to be able to do this but most of the 68k compiler backends have trouble generating good enough code for an instruction scheduler to make much of a difference. The superscalar CPU just ends up executing instructions in parallel which shouldn't even exist.

[Michael]

Under fast emulation, you can exceed 999 Mips, and get a result like 000.00
Maybe it would be possible to drop precision by one digit and show xxxx.x results
when we are running fast.

[Prosonic]

wow thanks I was using the original the other day wondering what happen to this guy

[eXeler0]

Originally Posted by Prosonic

wow thanks I was using the original the other day wondering what happen to this guy

The old 3.x version is pretty ancient but the 4.x version is still developed by this nice fella @Geijer.

Skickat från min HTC One via Tapatalk

[TuKo]

SysInfo 4.1b15 seems to crash with 68040 without FPU (reproducible under UAE) when running speed test. Is there a new beta version that fix it ?

[Geijer]

Originally Posted by TuKo

SysInfo 4.1b15 seems to crash with 68040 without FPU (reproducible under UAE) when running speed test. Is there a new beta version that fix it ?

Thanks, CPU / FPU / MMU detection is redesigned in the next beta, I have to test if there is still a problem.

[Schoenfeld]

Sysinfo 3.24 shows different speed results if you start it once, then move a few windows or do "avail flush" and restart it. I guess that the speed test code is depending very much on cache line alignment: If the core routine can take advantage of a full burst (4 longwords), it's faster and shows a higher value, although the machine is identical.

Is it possible to re-align the routine in fastmem to an address that has the lower 4 bits =0? Or even "configurable", so the routine is shifted in memory by 1-3 long words and the four values of four speed runs are shown in some debug window? Would be great to have the speed rating reproducable.

Another tool I use in accelerator development is "Bustest". Sometimes I think that an additional "speed" button on a memory list entry would be nice. Well, if you want additional items on your todo list ;-)

Jens