Author: Jo Even (hordaland.dnb.no)
Date: 01-23-2002 11:57
FatRakoon wrote:
>>Thats not quite correct
> Well, I know that, but you see what I mean!
I see what you mean, and that's not correct ;-)
> Yes, but at a pinch, a re-write of TOS
> would be a great help and it must surely
> be a hell of a lot heaper, and give access
> to the masses ( er? )
It will be a lot cheaper, but you won't gain any speed. Realistically speaking, it's not possible to get any better performance than MagiC does today. In theory it's possible to tweak every bit of code manually, but this would make such a large project unmanagable og very difficult to maintain and upgrade. Also, the code will only be marginally more efficient, you'd probably not notice any difference.
And don't forget that performance is more than speed, it's also a question of reliability. Code that's optimized for speed only will most likely have more bugs, and bugs will be harder to fix. Usually, it also means a more restrictive design which is hard to expand.
We could get better performance by redesigning elements of the OS, but this also means it won't be compatible with existing applications.
>>MagiC's VDI is actually a subset of NVDI,
>> so it should be fast enough... It's
>> doesn't have a GDOS though.
> Well, thats probably true, but adding NVDI
> still makes the GFX far faster than not
> having them
This is definitely not true on my Stacy. The difference in speed is very small.
> So, you are telling me that having a fully
> M/C rewrite of TOS wont be that much
> faster?
No, that's not what I'm saying. I'm saying that whatever TOS-clone you make, it won't be noticable faster than the existing clones. Also, if you leave the VDI and lack of disk cache out, you won't gain much speed compared to TOS either. And we already have replacements for those parts of TOS.
> come on, surely you are not that blind?
The efficiency of the OS *code* has very little to do with how fast your computer is, simply because the OS for the most part doesn't do anything at all. In our case, the only things the OS actually spend some CPU cycles on, is shifting pixels and shuffling bytes to and from the disk. A VDI-replacement and disk cache improves speed a lot, a GEMDOS-replacement can improve speed but not really by much (unless it has built in cache handling and a cache, like MiNT).
The biggest problem with TOS isn't that it's slow and inefficient, but that it has lots of bugs. MagiC and MiNT fixes this. NVDI, MVDI, Nova-VDI and fVDI are faster and better VDIs. N.AES, MagiC and soon XaAES are better AESes.
> Actually I cannot really comment on Disk
> speeds with MiNT because I have found them
> very slow compared to Magic.
I know from your previous postings. My offer is still valid, contact me and I'll help you sort out the problems with your setup.
> No, thats not what I am saying. I am
> saying that Kobold is TOS Compatible, so
> using Kobolds routines instead of TOSs
> will make the system faster, and it will.
No, it won't. Kobold is only faster because it is designed and optimized for a few simple operations. There is no way you can make a complete filesystem out of it and keep the same performance everywhere. With a lot of work it might end up just as fast as the FAT-implementations in MagiC and MiNT.
> ext2fs is NOT TOS compatible is it?
Why not? If TOS supported ext2, it would be TOS-compatible, wouldn't it?
|
