@ Karlos
Once again nothing but your own personal opinions on this (just as my posts are).
Your posts may be your personal opinion but mine are based on my experience. I tend not to rely on opinion when I can just get data from physical testing and I tested 4.0 before release and ran many like-for-like comparisons against 3.1, 3.5 and 3.9 on my system. I don't have the tables in front of me, but I can well remember the overall observations:
* OS4 graphics performance on AGA was on par with AGA + 68040 running fblit for most graphics.library drawing operations. Some faster, some slower. Access to Chip RAM is evidently the bottleneck for both. The 68040 scored slightly higher in raw memory transfer tests to ChipRAM than the PPC (both on 3.x/WarpOS and OS4) so theoretically it could be a bit faster for certain rendering operations.
* CPU-bound performance for PPC native recompilations of code was anywhere from 3-10x faster than their 68040 counterparts on OS3.x depending on how much memory access versus computation was involved in their inner loops. Figures for floating-point heavy code were higher still.
* CPU-bound performance for non-JIT 68K applications were typically lower (the slowest I managed in a synthetic worst-case test was about 1/10th the speed) but in normal cases not unusably so.
* CPU-bound performance for JIT 68K applications were typically on par or faster (wide variation in results) with the 68040. Some synthetic tests showed emulated 68K performance approaching native speed, but real code tends not to be that well "tuned".
* DiskIO-bound performance via the onboard IDE was on par with 68040, again, entirely as expected since the hardware interface is the bottleneck.
* NetworkIO-bound performance with large file transfers via Roadshow using the 68020 cnet.device was about 30% faster than AmiTCP4 on 68040 using the exact same version of the cnet.device.
And here's the rub. Most of the time you aren't even running CPU bound code, your applications are waiting for something. An InputEvent or timer interrupt or whatever. It's only when you start doing something intensive, like decoding a datatype that you really notice the difference that your 4-fold increase in clockspeed, bigger caches and faster FPU have given you.
Then again, you did say you found the latter (datatypes) to be one of the worst things ever invented and go to lengths to avoid using them so assuming you were sticking to old 68K applications that might in turn be running interpretively on your emulated 020, perhaps you are experiencing sub-par performance. But if that is true, then it's clearly a PEBKAC issue.
My remarks in regard to the the slowness of OS4.0 in my case are not "Exaggerated". As I already in the past told you I tried your suggestions but they made little or no difference to the speed or performance... 
Then you need to dig and find out why, because your experience is clearly strange, at least from where I am standing. Look at it this way: You have a CPU that is potentially several times faster than your 68K for almost any operation but is, according to you, turning in slower performance. This, on a playing field you claim to have levelled by removing all the RTG intended eye candy as per my suggestions previously. Now, if that was the case for everybody else then you could comfortably say that something was inherently wrong with the OS and it's just really slow and I'd have no choice but to agree with you.
However, you have another user (in this case me) that has used the same OS on equivalent hardware and has not reproduced your experience when doing the same thing. Even the most elementary Sherlock Holmes moment should make you stop to consider "perhaps something is up with my configuration, after all it isn't that different to his".
If it was *my* system that was crawling, especially after making all reasonable changes to the configuration to mitigate the AGA performance issues and someone else was insisting that better performance was achievable I'd be pulling my rig apart to find out what the problem is.
I was under no "Delusion" of any kind but was sold a product that failed to mention in any of the advertising or even on the box that a GFX card was required to get it to perform at a decent speed,
I'm pretty damned sure it was advertised as recommending a graphics card, certainly everywhere I looked. In the same way that most software cites a minimum specification it can physically run on but that's about it. It's not even as if it was the first version of AmigaOS that this was true for:
http://www.amigahistory.co.uk/os35.htmlMid-range performance
68030 or higher processor
8 MB Fast RAM
Graphics accelerator and/or scandoubler
Modem
In case you missed it, a "graphics accelerator" was the parlance back then for an RTG supported graphics card. Is there any reason at all to assume a later OS would go backwards in requirements?
all that was ever stated both in the advertising and on the very box itself was that a PPC board was required, not one single word about requiring a GFX card... 
So there was no "Delusions" on my part, more like false advertising on the sellers part...
Strange, I always assume the minimum specification stated on any product is what you'll need for it to simply run but have no expectations beyond that. For instance, had I not have gotten the RTG card, I categorically *would not* have bought either OS3.5 or 3.9, since whilst they both work without, it's abundantly clear you get much more out of it with.
I laugh at how you always like to say "end of story" as if your word is the be all and end all of any given subject, time you got your head out of your rear end and realised your not the only one around here who knows about the Amigas capabilities...
I never claimed I was the "only one that knows about the Amigas capabilities", but I do know that OS4.0 runs as well on my AGA installation as 3.x does *if* I spend time messing around with it's configuration.
As for your last trite comment in that post, OS4.0 was sold as only requiring a PPC board nothing ever mentioned about a GFX card so from that it's perfectly reasonable to assume from the details given by the seller that if all you need is a PPC accelerator and the OS is written in native PPC code then it would be reasonable to assume the it would run faster than even an specifically written 060 piece of code... :p
It can, except when it's struggling to access your chip RAM for any reason whatsoever. Look, there's a bloody good reason why Phase5 put an expansion slot on the accelerator board and it came as no surprise to anybody owning one that the first device they released for it was a graphics card, then a PCI busboard. By far the biggest bottleneck on the card is the trapdoor slot that connects it to the motherboard (and thus the Chip RAM). If you thought the 68060 was penalized when writing to Chip RAM, it gets off lightly. In the time it takes your PPC to do just one 32-bit write to chip ram it could literally have executed a dozen or more instructions.
So as usual on this subject your comments are typically flawed and based on nothing but you own opinions , so please stop with the high and mighty act that your word is somehow better than anyone else's and your "end of story" nonsense you like state so often is a cop out for things you have no answer too...
No, they are based on my experience, which as I've said is contrary to yours. However, there's no obvious reason at all why your system should be slower than mine, as far as I know the PPC chip is the same basic speed (240MHz?). If the software can perform acceptably on mine, then it must be capable of doing so on yours or anybody else's.
There were plenty of things wrong with 4.0 classic, especially in terms of support for hardware available to 3.x users, but basic performance for processor intensive tasks was not one of them.
