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

[Love Nystrom]

>  
>  ---------- Forwarded message ----------
>  From: Timo Kreuzer <timo.kreuzer(a)web.de>
>  Subject: Re: [ros-dev] MP/UP HAL issues
>
>  Am 26.03.2011 11:45, schrieb Love Nystrom:
>  
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.
>  
Ah.. Yes, *code clarity* (and proper comments) is of course a primary. We
all know the headache
of fixing code we wrote a year ago and didn't take the time to make
stringent and/or comment properly.
Btw. when I mention performance improvements, I meant in the order of at
least > 5-10%.
We all know that's never achieved by a cpl of asm tweaks, always by improved
algorithms.

As for Win7 I can't tell either way, since I don't have it..
Just a general note that apps that would fit well in 3MB RAM if written
properly, now seem
to hog up at least 30MB wherever it comes from, and runtime has gone the
same way.
C# + .NET issue perhaps? Or just incompetent newbie programmers running
amok?

Dropping single core processor support sound like a bad idea to me.
>  
>  Tell that MS, they did that with Windows Vista already.
>  
I tried telling MS a lot of things.. Like fixing some of their bugs that
*still live* since
the days of NT4 at least. All I I ever got was a blatant "Won't Fix". So..
F
them!

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).
>  
I understand.


>   This way we save us the complete MP kernel build time
> (almost 2 minutes on
>  my machine).
>  
Well.. as I said.. personally I don't give a hoot about another 2 minutes
build time.


>   IMO it would also make it easier to maintain the SMP
> kernel.
>  
Now *that* (code clarity and maintainability) is a more important issue IMO.
In my book, that usually means using *the same code* with *minor* precomp
switches.

WBR // Love

>  
>