Re: [ros-dev] MP/UP HAL issues

[Love Nystrom]

>  
>  ---------- Forwarded message ----------
>  From: Timo Kreuzer <timo.kreuzer(a)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

[Javier Agustìn Fernàndez Arroyo]

+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(a)gmail.com>wrote;wrote:

>   ---------- Forwarded message ----------
> >   From: Timo Kreuzer <timo.kreuzer(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Timo Kreuzer]

Am 26.03.2011 11:45, schrieb Love Nystrom:
>  
>      ---------- Forwarded message ----------
>      From: Timo Kreuzer &lt;timo.kreuzer(a)web.de <mailto:[e-mail]>>\
>
>  [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

[Olaf Siejka]

"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.