|
|---|
| | 
Gunnar von Boehn
(Apollo Team Member)
Posts 6263
25 Jan 2021 06:47
| We are right now working on RELEASE6 for V4. Release 6 is planned to give several improvements.
Besides better games and demos compatibility. Also a Disk Cache is included in the Kernel.
As you can see the performance under cache hit increases to nice 170 MB/sec.
| |
| | 
Robert Pulfer-Ridings
Posts 59
23 Feb 2021 23:05
| Can't believe there were no comments to this post, thats awesome! d:)
| |
| | 
Henrich Raduska
Posts 62
24 Feb 2021 00:18
| In a multitasking environment, zero CPU free time is a bad idea. UDMA can solve it.
| |
| |
Gunnar von Boehn
(Apollo Team Member)
Posts 6263
24 Feb 2021 07:07
| Henrich Raduska wrote:
|
In a multitasking environment, zero CPU free time is a bad idea. UDMA can solve it.
|
I know what you think but actually the best idea is to do the job in the shortest amount of time. The free CPU time is like: When you are waiting at the bus stop for an hour, its nice that you can in parallel listen to your walkman. But its even better when you NOT waiting at all! And exactly the very same applies for diskreads.
Lets say that "you mouse click on your workbench folder".
Now your Amiga OS will read the content of the folder, and will read the icons to be able to then render the icons on screen.
This means the OS is waiting for the Icons to be read
and the OS has to wait for this actively. While it not hurts when reading leaves some free CPU,
the most important is that the reading is done fast. Remember that if you read 100 times faster, then you you done in 1% of the time, and this leaves you with 99% free CPU after the read.
This is the best for the OS.
| |
| |
Henrich Raduska
Posts 62
24 Feb 2021 08:15
| This may apply for non-multitasking systems. Because storage devices are much slower than RAM, CPU must wait for data from device in loop. But in this time CPU could execute useful code.
You can try, for example, switch off UDMA support in PC device driver and try write CD od play video from this device. You can not, because even the fastest CPU has not enough time to prepare data for writing or can't reading and decoding video simultaneously. UDMA modes were not created to the delight of manufacturers, but from the need not to block the processor during data transfer from storage.
EXTERNAL LINK
| |
| |
Gunnar von Boehn
(Apollo Team Member)
Posts 6263
24 Feb 2021 08:21
| Henrich Raduska wrote:
|
Because storage devices are much slower than RAM, CPU must wait for data from device in loop.
|
You miss the point here.
We talk here about an operating system disk cache.
So we speak here about memory to memory copy!
| |
| |
Henrich Raduska
Posts 62
24 Feb 2021 08:45
| I know I'm a little off topic. I just wanted to write that it would be better to do support for UDMA modes for the smooth running of the system.
| |
| | 
Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
24 Feb 2021 13:17
| Henrich Raduska wrote:
|
I know I'm a little off topic. I just wanted to write that it would be better to do support for UDMA modes for the smooth running of the system.
|
Every progress is good. Disk caching finally!
UDMA could be next :)Henrich Raduska wrote:
|
This may apply for non-multitasking systems. Because storage devices are much slower than RAM, CPU must wait for data from device in loop. But in this time CPU could execute useful code.
You can try, for example, switch off UDMA support in PC device
|
While this is certainly true, and IDE tends to eat quite a lot of CPU time, smart solution is to load multitasking applications before extensive disk reading and writing starts. Also, since Amiga apps are from 90s mostly (small and not so CPU/mem hungry) and 080 is might CPU, I dont expect e.g. mp3 playback to start behaving badly. Maybe if you render that would slow down for a time of loading, but as Gunnar observes, would return to fastest state as soon as disk operation is done. One downside of AmigaOS was having a lot of small files to read, like icons, and disk caching is great speed up in this area.
| |
|
Performance and Benchmark Results!