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