PC still playing Amiga catchup

[stefcep2]

In case you hadn't noticed, the PPC board has a 68K processor that runs pretty much everything in OS3.x. The PPC itself is totally irrelevant as regards the boot time.

Is it?  I seem to recall that the 68040 on a ppc card was slower at the same clock speed than a non-ppc 68040.  
 

You said "from the moment the hard disk light goes out".

To mark the end of the boot process on the Amiga, and to distinguish it from  PC's which are still loading stuff off hard drive and people say the PC has stopped booting coz they can bring up a stuttering start menu

There's no swap file because you don't get any virtual memory support in 3.x. One other basic feature taken for granted on pretty much every other modern OS.

you don't need virtual memory when you have a very efficient OS and lean apps.  And if you really want it you can still do it.  *I* have NEVER run out of RAM, but I concede someone somewhere out there might need more than 128 meg.  In which case virtual memory can be done.

Tell me Karlos, with 4 GB of ram running at 1333 mhz and 4 CPU cores with caches that are big enough to hold the entire AmigaOS 3.1, why does your PC need a swap file even when you have nothing but a clock utility loaded?  Surely there's enough RAM there, and its faster just to load stuff in and out of your superfast, huge capacity RAM and CPU Caches rather than reading and writing to an albeit superfast Hard drive?

[stefcep2]

I'd like to see how long it takes an 060 (or even a 240MHz 603e) to open a 78MP (446MB) TIFF image, just for comparison, it took me 4 seconds

That settles it then...

[adz]

That makes 6-6-6-21 (the current settings) look pretty good from here...

Yah, 6-6-6-21 is nothing to be sneezed at, now overclock that sucker!!!

[Karlos]

Is it? I seem to recall that the 68040 on a ppc card was slower at the same clock speed than a non-ppc 68040.

Only when the PPC is accessing memory and the 68K wants to. Otherwise not really. The PPC cache is ample enough that the critical bits of the warpos kernel can fit in there whilst it's doing nothing.

[Karlos]

Yah, 6-6-6-21 is nothing to be sneezed at, now overclock that sucker!!!

When the CPU is cheaper to replace, I'll do it :lol:

[adz]

When the CPU is cheaper to replace, I'll do it :lol:

Chicken...buck-buck-buckaw! :lol:

[adz]

That settles it then...

No, just offering a real life example, not much point in only comparing boot times is there?


edit...Wonder how many negative points this thread will earn me :lol: :lol: :lol:

[Jakodemus]

My Atari ST has build-in midi-ports, the whole OS is on ROM and 68000 runs at 8mhz. It is better than amiga and pc combined!!111!!!1!!11!!

[Karlos]

Chicken...buck-buck-buckaw! :lol:

Stock intel CPU cooler, you see. Having said that, it isn't bad. I haven't seen it go over 45C yet.

[amigaksi]

@amigaski



As I said in the same post you have just failed to comprehend before replying to, if you don't use the OS and bang the hardware, then WTF is stopping you using the CPU for precision timing?

http://en.wikipedia.org/wiki/Time_Stamp_Counter

Turn off clockspeed altering power saving modes or use the constant TSC if present. Create an asm function for timing. Lock your code to one core (on multicore) and write a busy loop with a suitable instruction to prevent OOO execution and count the bloody ticks until you hit the magic number you've determined based on the reported frequency of your TSC.
...

You forget the other problems associated with RDTSC.  I am familiar with RDTSC as I mentioned it in the very post you are replying to (post #113).  You claimed it's accurate to a few machine cycles but that's complete rubbish.  In order to use in a generic way, you have to calibrate the RDTSC to the processor you are running on.  The calibration requires another timer; thus dropping your accuracy down to the accuracy of the 2ndary timer.  RDTSC is not always running at CPU frequency; some have tied to bus clock.  Power management affects it and there's no way to shut that down on some systems and on a Toshiba Tecra where I did shut down the power management the system became hot as the fan did not turn on and the system shut-down.  There are also SMIs implemented in some systems which cannot be disabled via applications and they cause frequency shifts and also halt tick counts during some C-states of the processor.  What constant TSC are you talking about?  So far on all the processors I have tried, RDTSC varies according to processor speed and the frequency of processor speed isn't some exact 90.00000Mhz.

>Quit your moaning about 850ns resolution hardware clocks. If you are a low level coder then the above tick timer should prove no problem. It should work on pretty much anything since the pentium.

Sorry, even if I use RDTSC and somehow avoid the above-mentioned problems, it's accuracy is the accuracy of the timer used to calibrate it-- 840ns for PIT.  So problem remains.

>Or, if all that is too much of a PITA, you could, assuming you have a reasonably recent PC, just use HPET[/QUOTE]

The fact that they introduced the HPET which runs at lower frequency than RDTSC should tell you that RDTSC proved to be not that reliable.  HPET is not present on my latest 2.8Ghz machine so not worth using it since that means it won't be present on majority of PCs.  There are other issues that affect it's accuracy as well.

[amigaksi]

Re: Joyport / Parallel port. Current PC's don't have either port to compare against. Your inability to use your "low level" coding skills to write an accurate timer for x86/HPET is no reflection on the hardware..
...

A few people here in this thread have referred to items that are NEW or nonexistent (exist in spec only).  Those are useless for a common application.  I have written accurate timer using 8253 under Windows XP, but it's accuracy is 840ns (less than an Amiga).  Amiga's accuracy is 558ns and HPET cannot be used to compare with it and RDTSC has problems as already mentioned.  I just remembered another problem with RDTSC-- it's nonserializing; so I also have to make sure I write some special instructions after and/or before it to prevent it from executing in parallel.  So much for your speculation that it's accurate to a few machine cycles.

>Re: bootup times:

>From cold, timed this morning:

I think one good test for boot-up time is is how long it takes to boot-up until you can run your specific program that uses OS functions.  You can launch Amiga programs directly from command line via startup-sequence.

[Karlos]

A few people here in this thread have referred to items that are NEW or nonexistent (exist in spec only).  Those are useless for a common application.  I have written accurate timer using 8253 under Windows XP, but it's accuracy is 840ns (less than an Amiga).

Joyports are nonexistent on PC's for some time now, but you are insisting on using it in your argument.

Amiga's accuracy is 558ns and HPET cannot be used to compare with it and RDTSC has problems as already mentioned.  I just remembered another problem with RDTSC-- it's nonserializing; so I also have to make sure I write some special instructions after and/or before it to prevent it from executing in parallel.  So much for your speculation that it's accurate to a few machine cycles

I think you'll find I already pointed out that as a requirement when writing the loop, along with locking it one core on multicore and preferring constant TSC where available, or preventing speed step from altering the core speed. Not my fault if you can't be arsed to read the CPU documentation properly.

Also, other than dismissing it outright, you haven't given any reason why HPET is unsuitable for your timing requirements.

>Re: bootup times:

>From cold, timed this morning:

I think one good test for boot-up time is is how long it takes to boot-up until you can run your specific program that uses OS functions.  You can launch Amiga programs directly from command line via startup-sequence.

No, that's an entirely synthetic test invented by you. Under your stated circumstances, my chosen application is Workbench...

[amigaksi]

Joyports are nonexistent on PC's for some time now, but you are insisting on using it in your argument.



I think you'll find I already pointed out that as a requirement when writing the loop, along with locking it one core on multicore and preferring constant TSC where available, or preventing speed step from altering the core speed. Not my fault if you can't be arsed to read the CPU documentation properly.
...

Did you miss a post regarding RDTSC from me?  I stated that I shut down power management to prevent RDTSC from misbehaving on a Toshiba and the system overheated.  How do you prevent processor from going  into SMIs and C-states and stopping tick counts?  It's not in any Intel reference I have.

>Also, other than dismissing it outright, you haven't given any reason why HPET is unsuitable for your timing requirements.

The fact that it's not in any of my 10 PC systems is good reason to dismiss it for now.  The fact that it won't work on majority of systems out there is another good reason.  The fact that it's accuracy is affected by other IRQs in the system is another good reason.  I can mention more but why waste time with it if I can't use it generically.  By the way, Amiga timer is 558ns w/o +/- bullcrap (as I stated); HPET has a +/- latency as well attached to it.

>No, that's an entirely synthetic test invented by you. Under your stated circumstances, my chosen application is Workbench...

If you use Amiga for some specific application, it can launch faster before you load WB.

[amigaksi]

Joyports are nonexistent on PC's for some time now, but you are insisting on using it in your argument.

...

I wanted to keep the joystick argument separate from timer stuff since it was over.  Joystick gameports are in millions of existing PCs and they suck; they are inferior to Amiga's joystick ports.  If you can't live with this fact of REALITY, that's not my problem.  You can still get gameports on audio cards and they were supported by Windows XP which is not obsolete for many.

[Karlos]

Did you miss a post regarding RDTSC from me?  I stated that I shut down power management to prevent RDTSC from misbehaving on a Toshiba and the system overheated.

LOL, excellent

How do you prevent processor from going  into SMIs and C-states and stopping tick counts?  It's not in any Intel reference I have.

Did the part not actually have a constant TSC register? Most current intel processors do.

>Also, other than dismissing it outright, you haven't given any reason why HPET is unsuitable for your timing requirements.

The fact that it's not in any of my 10 PC systems is good reason to dismiss it for now.

Are you sure? It could just be that whichever version of the OS you are using doesn't let you use it.

 The fact that it won't work on majority of systems out there is another good reason.  The fact that it's accuracy is affected by other IRQs in the system is another good reason.  I can mention more but why waste time with it if I can't use it generically.

But this is true on the PC for most things. Very few applications that need to bash the hardware directly are going to be universally compatible

By the way, Amiga timer is 558ns w/o +/- bullcrap (as I stated); HPET has a +/- latency as well attached to it.

Maybe not, but you can't possibly be suggesting that whatever code you execute every 558ns isn't going to add latency.

>No, that's an entirely synthetic test invented by you. Under your stated circumstances, my chosen application is Workbench...

If you use Amiga for some specific application, it can launch faster before you load WB.

Well, by the same token, I could roll a linux kernel that gives me just what I need to run "nano" and edit a few files.

The point is, I haven't used custom OS boot disks on an amiga since the day I got my first hard disk. Which was a long, long time ago.

[amigaksi]

LOL, excellent



Did the part not actually have a constant TSC register? Most current intel processors do.

...

It only talks about fixed counter using bus clock as opposed to processor frequency, but even the bus clocks vary with systems.


>Are you sure? It could just be that whichever version of the OS you are using doesn't let you use it.

No, remember I'm a low-level programmer so I went through the BIOS RSDT/FACP tables to detect the HPET table in DOS32 and it does not exist.

>But this is true on the PC for most things. Very few applications that need to bash the hardware directly are going to be universally compatible

HPET/RDTSC/PIT/Keyboards/VGA/IRQs and some other things are amongst those that have standard means of detecting and using directly at hardware level.

>Maybe not, but you can't possibly be suggesting that whatever code you execute every 558ns isn't going to add latency.

Copper executes the instructions at the exact cycle you want it to (558ns accuracy).  If I use processor frequency or CIA interrupts, I run into latency issues.

>Well, by the same token, I could roll a linux kernel that gives me just what I need to run "nano" and edit a few files.

Yeah, but I don't think it works in XP/Vista.