When I said neglectable runtime performance, I meant something that you wouldn't notice even if you were benchmarking the system.---------- Forwarded message ----------
From: Timo Kreuzer <timo.kreuzer@web.de>\
[abbreviated]
I'm against wasting precious compile time for an MP hal that doesn't even work. And I would actually like to have the kernel being compiled the same way. I bet the performance improvements of inlining some spinlock code are really neglectable.
I hate being a spoilsport, especially on an issue that may have gone stale already,but *compile time* is not even 10% as important as *run time*.I dunno about the particulars in this case, it's just a general priority opinion.
And what if it makes the code harder to read and maintain or if its likely to introduce bugs later? Performance is great, but you need to be reasonable. Saving a few clock cycles, saving you a microsecond per minute runtime is not worth downgrading code quality. Its not even worth massively increasing build time.
To me, performance is *everything* ..I gladly spend a *week* to gain significant performance,especially if it also makes the code clearer and more readable!
If you look at Windows 7 improvements then you will notice that there are a lot of performance improvements. It generally runs faster then Windows XP. This is not achieved by saving a few clock cycles here and there, but by improving algorithms and adding additional features.
Is it just I who think that software is getting slower and slower and bigger and bigger these days?And I mean particularly the goo gaa that comes out of Redmond these days :-/
Tell that MS, they did that with Windows Vista already.I'd even go as far as dropping UP support completely and hotpatching spinlock functions.
Dropping single core processor support sound like a bad idea to me.