Welcome, Guest. Please login or register.

Author Topic: A-EON Interview about Amiga's future - Distrita  (Read 11147 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: A-EON Interview about Amiga's future - Distrita
« on: June 08, 2015, 09:03:53 AM »
Quote from: Thorham;790781
You don't need those, because you can use bset and bclr. These instructions test the bit they set or clear before writing to the bit. With this you have test then set and test then clear. Perfectly fine for such mechanisms.

When you are programming in higher level languages you dont have those assembler instructions available. The compiler may generate code using those instructions but it is not guaranteed. For example Intuition manual recommends using Forbid()/Permit() pair if you are toggling flags in your Window structure.

Forbid()/Permit() pair is also fundamental part of AmigaOS design. When you are scanning certain system lists you must arbitrate access with these. When Workbench launched program is returning it must call Forbid() before exit. If you are sending a message to public message port you must use Forbid() for protection. Many functions in the OS are serialized and are executed in Forbid() like memory handlers and library init/expunge functions.

Semaphores in AmigaOS are internally using Forbid(). AllocMem() is using Forbid() and it is very slow function what hampers multitasking very badly if called repeatedly.
« Last Edit: June 08, 2015, 09:07:58 AM by itix »
My Amigas: A500, Mac Mini and PowerBook
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: A-EON Interview about Amiga's future - Distrita
« Reply #1 on: June 08, 2015, 05:14:18 PM »
Quote from: matthey;790765
True. Any task can take over the system and turn off multitasking so it is not secure but it is preemptive multitasking by definition. Responsiveness was traded for security.

I feel the AmigaOS has been slighted (not by mongo). The AmigaOS is one of the best and most responsive OSs at multitasking (near real time OS made the Toaster possible).


I am not so sure is this true. If Amiga multitasking is so good why MP3 players or CD burners need large buffers?

To me it seems multitasking on Amiga is unpredictable.
My Amigas: A500, Mac Mini and PowerBook
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: A-EON Interview about Amiga's future - Distrita
« Reply #2 on: June 08, 2015, 10:36:14 PM »
Quote from: matthey (& to ThoR);790818
Paula's audio buffer size is limited by the custom chips (easily fixed with enhanced custom chips). The Amiga serial ports were limited to low speeds because of limited buffer size support. Amiga IDE was limited by small buffer sizes (and old PIO modes) until the 4000T. Without proper buffer sizes, the CPU has to do more work and the Amiga with 68k CPU has a limited pool of CPU cycles to start with. Buffer sizes were probably adequate when the Amiga was created but were barely or in most cases not upgraded with ECS and AGA. The Amiga did receive expansion boards and accelerators which fixed many of these bottlenecks.

I am not sure is this related only to slow I/O. For example your real time application, is it still working right if you have GCC compiling large source code at background at lower priority?

Try to run simple non-IO real time task at priority 0 and GCC below 0.

You might find out that GCC is loading some files from the disk and this is delegated by the OS to tasks running at higher priority than your task. Suddenly your real time task is blocked by the OS serving low priority tasks.

To me it seems that if you dont raise your own priority over OS tasks you dont get served as expected. It doesnt matter how fast your system is. As long as you are running at priority lower than 10 the scheduler cant guarantee you fair share to the CPU.

Quote
Try installing Windows XP on an old 386, 486 or Pentium CPU to see how responsive it is in comparison to a 68k Amiga.

But Windows XP has lot more features than Amiga, like memory protection, built-in TCP/IP and USB stacks, and bunch of services (like you mention below).

Quote
I had the fan die in an old laptop with Pentium M (roughly the performance of a Pentium III at the same clock speed but more efficient on power) which caused the clock speed to run at 800MHz. Responsiveness was worse than most 68k Amigas even though it had some processing power in slow motion. These modern OSs with their security, features and bloat have a lot of overhead. MOS PPC Macs also are more responsive and performance efficient than with their previous Mac OS X. Any surprise?

Sure. No surprise there. But on the other hand raw performance is still same. Heavy computational tasks run roughly at same speed and it is not possible to have significant gain in the RC5-72 contest for example.
« Last Edit: June 08, 2015, 10:54:47 PM by itix »
My Amigas: A500, Mac Mini and PowerBook
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: A-EON Interview about Amiga's future - Distrita
« Reply #3 on: June 09, 2015, 06:17:42 PM »
Quote from: Thomas Richter;790842
As far as the Amiga task system works, it should. A higher priority task will always pre-empt a lower priority task. Thus, whenever your "real time" (something like that does not exist on the Amiga) application requires the CPU, and it has a higher priority than the background job, it gets the CPU.  It's not quite as bad. The FFS has a higher priority, yes, but it does not do much. It just prepares a couple of buffer pointers and then gives control back to the hardware abstraction level aka "device".

Here, again the game is the same: If you have hardware that is smart enough, the device will only initiate a DMA, and hence give control back to the foreground job as long as the transfer is running. CPU time is not "burned" while waiting for the I/O.

This is only true when you are reading file sequentially. You can do "nasty" things like ExAll() some huge directory. Likewise using Examine()/ExNext() is "friendly". But again MatchFirst()/MatchNext() with the callback hook... even just Lock()ing a file is relatively expensive operation.

Big oops.

Quote
If you are have a sorry "PIO-only" host adapter, you have a problem, though, because somehow somewhere the CPU needs to take the time from to transport the data from the disk to the RAM. That, then, of course, can really steal important time and make your day, and the device has no knowledge about which I/O it should initiate first as the origin of the request is lost. But that's not really the fault of the AmigaOs, but rather of the hardware requiring full CPU attention for I/O. It does not happen for DMA-based host adapters.

But it does happen when you use RAM disk or DynamiCache since they dont use DMA. Just unpack large archive to RAM disk...

I dont see where "near real time OS" comes from when conditions are random. Works most of time but dont do this or that.

Even just OpenLibrary() is enough to let higher priority tasks to miss their deadline as OpenLibrary() can have very long Forbid().
« Last Edit: June 09, 2015, 06:21:23 PM by itix »
My Amigas: A500, Mac Mini and PowerBook
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: A-EON Interview about Amiga's future - Distrita
« Reply #4 on: June 09, 2015, 11:12:10 PM »
Quote from: Thomas Richter;790861

Well, OpenLibrary() does have a Forbid(), but not a long one. It rather uses the Forbid() to scan through the library lists. If it does not succeed there, then exec (or rather, ramlib) calls Permit() and creates a message to the ramlib task to load the library from disk. As soon as the message comes back, it tries again. The amount of blocking imposed by OpenLibrary() is thus not higher than that of any other disk-based operation. Besides, any disk based operation will break a Forbid() since it includes a Wait(), or at least two: one of the task waiting for the filing system, and one of the filing system waiting for the device.


I was not thinking actual OpenLibrary() call but library init process (I was unclear). Some libraries precalculate data in libinit taking (relatively) long time to complete, especially on slower Amigas.

But this was just another example how unpredictable multitasking in Amiga is...

I know you know this stuff :-)
My Amigas: A500, Mac Mini and PowerBook
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: A-EON Interview about Amiga's future - Distrita
« Reply #5 on: June 10, 2015, 11:10:59 AM »
@Thomas Richter

Oh. Maybe I remember wrong. Apparently I have to check my reference code when I get home. All these details are getting more and more vague every year...
My Amigas: A500, Mac Mini and PowerBook