Hi Olaf,
From what you say AROS 68K is already or can already be a very good AMIGA OS replacement?
I'm sorry, this is not for me to say because I neither know the current state of affairs of the AROS 68k build, nor am I familiar with the AROS project as it is today. Before I could give you an assessment I ought to know what I'd be talking about, which I don't
If there are areas where performance could be improved like e.g EXEC, or LAYERS.
Would these be areas where some geeks ould help?
From the impression I got so far, it seems to me that the interest may be there, but the question is whether this is sufficient to polish the code as it is.
We are not talking about some old, small sized operating system component for which tangible improvements are easily achieved (the "low-hanging fruit" if you want to call it that). Any measurable improvements would have to come through analyzing and re-engineering the code. This requires a bit of experience and knowledge of the technology. Back in the day you could learn all that, and apply it, in a few years.
I have no idea how the talent situation is today. Let's see some code, that is usually the best way to get an impression of how well-prepared a programmer is to tackle Amiga software development.
I would assume Cosmos would be talented for tuning Exec?
And I would think that Thomas would be the perfect guy to do layer super fast?
Frankly, I cannot judge how far Cosmos' talents extend beyond the 68k assembly language optimizations he showed. Exec is pretty well-designed and well-implemented (actually, the InitStruct() stuff was partly obsolete when it shipped, and how Signal exceptions are handled makes you wonder why the API is incomplete), and the best thing you can do without making radical changes to the implementation seems to be to shave off the rough edges through small optimizations. The thing is, for optimizations to made in this type of software you both need to know the context in which your optimization would have to be effective, and you need to measure if the optimization actually did make things better. So far, from Cosmos' own words, he does not seem to be into measuring the effects, he prefers to infer the effect from the changes he made.
As for Thomas, you may not be aware of it, but he is a physicist by training, which accounts for his background in mathematics and computer science. He has lectured, published papers, etc. He's an actual scientist. Why is this important? Physics is an empirical science, which builds models of the world through the use of mathematics. To make sure that your models are sufficiently accurate representations of reality, you need to test and verify them. Any claim you can make about the models must be backed up by evidence. See where I'm going?
Thomas built his layers.library by analyzing how the original worked, built a new one designed to solve the same problem better and verified that it does accomplish this goal. This approach represents best engineering practice. As far as I know the performance improvements are significant and can be measured. These improvements are on a scale which exceeds what could be achieved by fine-tuning the underlying assembly language code. No matter how much effort you put into shaving cycles off an inefficient 'C' compiler translation of the original code, if that code uses a technique (algorithm) that solves the wrong problem, or solves it in such a way that it wastes time, then you still have a poor solution. What's the alternative? Replace the algorithm with something that is more suited to the task. This is what Thomas did.
Replacing the algorithm produces significant leverage. To give you an example: if you have used the standard file requester in AmigaOS 3.1 and 3.5 you may have noticed that there is a performance difference between the two. The original 3.1 version became noticeably slower the more and more directory entries it read and displayed. The 3.5 version did not become noticeably slower. This was achieved by replacing the algorithm by which the file requester kept the directory list in sorted order. In the 3.1 version, doubling the number of directory entries read caused the file requester to spend four times as much effort to keep the list sorted, and no degree of low level assembly optimizations would have helped to improve this. What did bring improvements was to replace the sorting algorithm, so that doubling the number of directory entries only about doubled the amount of time needed to keep it sorted.
This is how you get to "super fast", and Thomas is your man. Cosmos, I'm not so sure about.
