language_fan wrote:
Wed, 30 Sep 2009 12:05:29 -0400, Jeremie Pelletier thusly wrote:
Don wrote:
Greater risks come from using more complicated algorithms. Brute-force
algorithms are always the easiest ones to get right <g>.
I'm not sure I agree with that. Those algorithms are pretty isolated and
really easy to write unittests for so I don't see where the risk is when
writing more complex algorithms, it's obviously harder, but not riskier.
Do you recommend writing larger algorithms like a hard real-time
distributed (let's say e.g. for 100+ processes/nodes) garbage collector
or even larger stuff like btrfs or ntfs file system drivers in assembly?
Don't you care about portability? Of course it would be nice to provide
optimal solution for each platform and for each use case, but
unfortunately the TCO thinking managers do not often agree.
You deal with this by ensuring that you have a clear division between
"simple but needs to be as fast as possible" (which you do low-level
optimisation on) and "complicated, but less speed critical".
It's a classic problem of separation of concerns: you need to ensure
that no piece of code has requirements to be fast AND clever at the same
time.
Incidentally, it's usually not possible to make something optimally fast
unless it's really simple.
So no, you should never do something complicated in asm.
