2.6GHz WinUAE = 10 x 50MHz 68030

[whoosh777]

The Benchmark program Sysinfo tells me that
my PC is 100 x as fast as my 50MHz 68030
and 250 x as fast as my 50MHz 68882 FPU
(PC vs A1200),

sadly the truth of the speed up is a mere 10 x,

Building Ghostscript 8.13 on my A1200 takes some 16 hours,

but on WinUAE it takes 1 hour 38 minutes,

ie its only 10 x as fast,
and these 2 builds use identical binaries,
eg WinUAE Geek is binary identical to A1200 Geek,

The above build involves a lot of file i/o:
on the A1200 the hard disk is literally active
for hours eg recursively expanding out #include's,

I wondered whether if I built the program entirely in RAM
if it would build faster,

so I bought a 256 Mb USB2 flash ram drive called Disgo,

and copied my entire Geek environment and the entire
GS813 build environment into the flash ram drive,
these 2 environments eat up 145Mb in total,

the object directory also was on the Flash Ram drive,

this time the build took 2 hours 5 seconds, uh oh!

:flash ram is slower than hard disk,

ok, conclusion: in a real life real example the speed up is
10 x,

The PC is powered by a 2.6GHz/400MHz Intel Celeron with
256 MB DDR Ram,

My A1200 uses Blizzard 1230-II SCSI interface FFS hard drives,

Moral: benchmark programs are totally misleading, the only
way to compare speeds of 2 systems is to run the program you
intend to use on both systems,

Eventually I will also compare Cygwin (Windows Geekgadgets) and
PC AROS and WinUAE and A1200,

[Ilwrath]

The Benchmark program Sysinfo tells me that
my PC is 100 x as fast as my 50MHz 68030
and 250 x as fast as my 50MHz 68882 FPU
(PC vs A1200),

sadly the truth of the speed up is a mere 10 x,

Building Ghostscript 8.13 on my A1200 takes some 16 hours,

but on WinUAE it takes 1 hour 38 minutes,

ie its only 10 x as fast,

To me, a 10x improvement over a 50mhz 68030 sounds like a very impressive mark!  Especially for a processor as crappy as a Celeron!  

I mean, that's an emulated 500mhz 68030.  From a budget low-cache 2600mhz chip.  That's only 5 Celeron cycles per emulated 68030 cycle.  Honestly, I doubt the emulation (even with JIT) is that tight.  

As you found, file I/O plays a huge factor in compile times.  I imagine your Amiga HD is probably slower than the hard drive on your emulator.  This is slowing down the Amiga's compile time...

And, of course, the real moral is, don't believe artificial benchmarks run on emulated systems.  Aren't there 1000 threads about this on here?

[whoosh777]

@Ilwrath

/*
To me, a 10x improvement over a 50mhz 68030 sounds like a very impressive mark!
Especially for a processor as crappy as a Celeron!

I mean, that's an emulated 500mhz 68030.
From a budget low-cache 2600mhz chip.
*/

But Sysinfo says the emulated machine is 108 x as fast,
Sysinfo is not measuring the Celery chip but the emulated 68k chip,

can you put my CPU in perspective in terms of cache size + speed
relative to other Intel clones?

The startup seems to say 128K cache, I know that cache size makes a huge
difference to performance,

/*
That's only 5 Celeron cycles per emulated 68030 cycle.
Honestly, I doubt the emulation (even with JIT) is that tight.
*/

ok, I see what you are saying, 2.6GHz sounds much more impressive than
50MHz, but actually its just a ratio of 50,
so your numbers are exactly right,


what does the 400MHz mean in 2.6GHz/400MHz?

400 million cycles per second, but how many bits happens per cycle and where?

/*
As you found, file I/O plays a huge factor in compile times.
I imagine your Amiga HD is probably slower than the hard drive on your emulator.
This is slowing down the Amiga's compile time...
*/

Sysinfo crashes if I try to measure the disk speed on the PC,

if I access the file system on WinUAE it takes forever, eg typing tab for tab
completion can literally take minutes before the requester appears: even if there are
just 3 items in the requester,

on my A1200 tab completion only takes ages if there are a lot of items in
the requester,

cd and assign also can take forever,

I will try and do some experiments to determine whether the slow file access
is from WinUAE or if its an XP problem,

I have 4 shells currently: AmigaOS + Geek on WinUAE
and Cygwin + MSDOS on XP, so I will gradually
compare these different shells to try and pinpoint the
slowness,

Windows XP seems very secure in some sense of the word, so I wonder if
XP is doing some very inefficient vetting of each file access?

OTOH XP is very insecure in the sense that it is continuously under siege
from viruses, this system expects me to do a full Norton scan once a week,

I dont trust Norton, I think Norton is spying on everybody's system and submitting
reports to some CIA database. Is Norton looking for
viruses, or is it a spy?

Once a file is accessed then it can be processed unbelievably fast,

/*
And, of course, the real moral is, don't believe artificial benchmarks
run on emulated systems.
*/

IMO a lot of damage has been done to the Amiga market by lies about Windows
machines,

I have my setup now so that by turning a KVM switch I can alternate between
my AGA A1200 and this XP PC,

I am very happy with WinUAE except for the file access slowness,
the AGA emulation is very impressive eg it does perfect emulation of
AGA HAM8, it also correctly does slide down screens,

USB2 is said to manage 480 Mb/second, and the machine has a zillion
USB2 slots, however I cannot run my external USB2 hard disk and
the Disgo flash ram at the same time!

:so this USB2 cannot cope with just 2 USB2 devices, I phoned the manufacturer
of my PC and they say it may be a power problem, the Disgo drive takes
its power from the PC,

The PC also cannot cope with keyboard + mouse extensions beyond 1.8m,

my A1200 is quite happy with eg 5m extensions,

so I am finding my A1200 better engineered,

/*
Aren't there 1000 threads about this on here?
*/

probably, but I wanted to dispell some of the pro Windows FUD,

propaganda is based on the idea that if you keep repeating a
false statement often enough people will start believing it
at a subconscious level regardless of its falsity,

its Pavlovs experiment of the dog + food + bell,
eventually just ringing the bell made the dog salivate,

I have a book which says that Pavlovs experiment formed the basis of
the S.U's propaganda machine,

the never ending Windows FUD made me believe I was buying a
miracle machine, the only way to break the FUD is to repeatedly switch
between the 2 systems and do experiments,

There has also been anti Windows FUD, eg this PC is
very quiet and its not hot. So all that stuff about
PPC being cool and quiet, well so is my PC,

I think a big advantage of PPC is that it is a
very clean architecture, so it will probably
be much more immune to viruses and MS (IYSWIM),

[MarkTime]

I am glad you said flash ram is slower than hard disk.

I've been saying this for years, trying to help people realize that flash ram has a specific purpose, and speeding up operations compared to a hard disk, just isn't one of them.

Now flash ram will be getting faster in the next few years, and if it surpasses  hdd speeds, then an update to this information is due.

but for now...PEOPLE FLASH RAM IS SLOW, on top of that it has a more limited life...anyone buying these flash solutions for boot speed....just stop it.  ok seeks are electronic, you'll find a slight speed increase on seek times, but certainly not on sequential reads.

[Ilwrath]

But Sysinfo says the emulated machine is 108 x as fast,

Yes, but Sysinfo doesn't realize the machine is emulated.  What happens with the WinUAE JIT emulation is that the 68000 (020/030, whatever) series instructions are translated on the fly into x86 instructions.  During this translation there is an optimization phase to improve performance.  This stage is "optimizing" the benchmark, and making it invalid.  Most benchmarks work by looping through a section of code multiple times.  The emulation realizes what is happening, and keeps the translated code available, thus artificially raising speeds.  Or, sometimes, the JIT even optimizes the entire loop out of existance, and only returns a final result.  (Those are usually the things that crash, because the emulator returns such an outlandishly high performance result.)

So, you see, it wasn't out of FUD or malice that emulation benchmarks don't work.  It's that it's really hard to measure emulated hardware.  The emulation is often smarter than the tests.  ;-)

can you put my CPU in perspective in terms of cache size + speed

The 2.6/400 is a pretty fast chip, but it has some issues...  3.4/800 I think is the fastest P4 on the market.  (We won't go into Opteron and Itanium stuff here -- I'm trying to keep this fairly short, and not mis-state anything -- if I do make a mistake, someone please feel free to correct me.)  

Caching -- The Celeron has 128K.  This is rather small for a modern processor.  The P4 has 512K, and the P4 Extreme has a full 1MB.  Anyhow, cache is kind of the working area, of sorts, for the processor.  There's lots of complex formulas and associative theories on how processors determine what gets cached and what gets flushed, etc.  To be honest, I don't really understand that part too well.  It's magic to me.  But, obviously, a smaller cache can't hold as much data as a larger cache.  More about this in a bit...

Ok.... Front Side Bus.  The 400mhz is your FSB speed.  That's your link between the processor and it's RAM and Bus area.  The 400mhz is fast, but the full P4 is able to double that up, to an effective 800mhz.  (These numbers aren't quite real, there is some "Double Data Rate" trickery, as well as interleaving, etc.)  But, anyhow, the basic idea is that under some conditions, Celeron RAM access can be quite a bit slower than the full P4.

Processor clock...  2.6ghz is a mighty fast processor clock.  That's the rate that the processor can work at with data it already has in it's cache.  This is the strength of the Celeron.  It has a fast clock for cheap.  

So a Celeron is quite fast for highly optimized code that fits in it's cache.  Now, the problem is, when things don't fit in the cache.  This happens more often on the Celeron, because it simply has less cache.  And it's a double-whammy, because now you have RAM access involved, which is over the slower 400mhz (effective) bus.  

So more random/less optimized code can really bog a Celeron down a lot.  I would think that because of this, emulations would not run well on a Celeron.  I haven't actually put this to the test.  If you'd like, PM me, and maybe we can set up a P4 UAE test vs. a Celeron UAE.  Might be interesting results.  It may be a chance to prove my theory wrong.  

Anyhow, this concludes this lesson on processors and emulations, as I understand them.  ;-)

[Hammer]

whoosh777 wrote:
(SNIP)

One could use benchmarks such as Quake1 68K(SW render) or Cinema 4D 4.x.  

The PC is powered by a 2.6GHz/400MHz Intel Celeron with
256 MB DDR Ram,

One could try this type of activities on full featured X86 processor instead.

[Hattig]

I've seen (a lot of, not just a select few) benchmarks that put a 2.8 GHz Celeron processor roughly on par with a 1.6 GHz Duron (~£35) in terms of performance. I.e., the Celeron is an awful processor, both in terms of performance and in terms of value. Even worse is the likelyhood that your system is using integrated graphics, and taking more memory bandwidth away from the processor because of that.

But it is good that you did a full application benchmark, a compilation, rather than rely on dodgy benchmarking software that isn't valid these days.

Compilation can be disk bound ... of course you can work around this by doing it in a RAM disk on the Amiga ... if you have enough RAM anyway.

I expect you would get twice the performance from a top of the range processor (Athlon 64 FX-53, P4EE, etc) and near that from better value high performance processors (Athlon 64, P4).

[Karlos]

@whoosh777

The moral of the story is that emulated systems are pretty odd. Some stuff is lightning fast, but other stuff can be slower (AGA emulation in particular).

Try playing an AGA game that is also CPU intensive on a real amiga to see what I mean. I found the AGA version of AB3D 2 brings many a PC running UAE to it's knees (the ultra unstable RTG version absolutely flies at a ludicrous framerate, however. For about 10 seconds before crashing, that is).

There simly is no magic formula to compare the speed of an emulated system to a real one as you are discovering.

Compilation is, as you know, a very processor/memory/io intensive process. For a totally emulated system, 10x faster than a 50MHz 030 isnt too terrible - it's on a par with a decent 68060.

Actually thinking about it, I use UAE for compiling some stuff here. I have a pretty old PC built from spares and donations :-) It's an AMD K6-II 500MHz (100MHz FSB).

Some stuff that takes my 040 half an hour to compile (with all the optimisations) compiles in about 5-10 minutes using UAE. Perhaps your UAE settings aren't fully fine tuned :-?