---------- 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.
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!
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 :-/ But as everybody in the world seems to play "Follow John" with Microsoft, users are left with software where they have to go for a coffe break after giving a command before their multicore superduper computers even give a burp, because programmers care less about runtime than compile time these days :( Blame the RAD frenzy for that!
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.
W.B.R. // Love
+1 to that
lets make small, fast software!! :) (i.e. good software)
On Sat, Mar 26, 2011 at 11:45 AM, Love Nystrom love.nystrom@gmail.comwrote:
---------- 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.
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!
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 :-/ But as everybody in the world seems to play "Follow John" with Microsoft, users are left with software where they have to go for a coffe break after giving a command before their multicore superduper computers even give a burp, because programmers care less about runtime than compile time these days :( Blame the RAD frenzy for that!
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.
W.B.R. // Love
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Am 26.03.2011 11:45, schrieb Love Nystrom:
---------- Forwarded message ---------- From: Timo Kreuzer <timo.kreuzer@web.de <mailto: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.
When I said neglectable runtime performance, I meant something that you wouldn't notice even if you were benchmarking the system. We would need to examine this, since I can't say for sure if that's true.
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!
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.
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 :-/
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.
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.
Tell that MS, they did that with Windows Vista already. Also I wasn't even talking about dropping the up kernel, I suggested compiling it in a different manner, that would not allow inlining spinlock functions as its done currently, but would cause them to be called. The function would be linked as UP or SMP depending on whether we are using UP or SMP kernel (can be done at link time or even at runtime). This way we save us the complete MP kernel build time (almost 2 minutes on my machine). IMO it would also make it easier to maintain the SMP kernel.
Regards, Timo
"but *compile time* is not even 10% as important as *run time*."
I think Love that you do not imagine what is the impact of buildtime in our project. As ReactOS is not getting smaller, increased buildtime is simply slowing down development pace by a considerable margin. It might be a worthy tradeoff for a project with production version already, but not in our case. Reaching over 10 minutes of buildtime requires really top of the line hardware, not to mention dedicating whole host system to this task. For average team member, it takes not 10 but even over 30-40 minutes to do a full build. Time that is often so precious to spare.
-
Javier Agustìn Fernàndez Arroyo -
Love Nystrom -
Olaf Siejka -
Timo Kreuzer