Linked by Hadrien Grasland on Fri 28th Jan 2011 20:37 UTC
OSNews, Generic OSes It's recently been a year since I started working on my pet OS project, and I often end up looking backwards at what I have done, wondering what made things difficult in the beginning. One of my conclusions is that while there's a lot of documentation on OS development from a technical point of view, more should be written about the project management aspect of it. Namely, how to go from a blurry "I want to code an OS" vision to either a precise vision of what you want to achieve, or the decision to stop following this path before you hit a wall. This article series aims at putting those interested in hobby OS development on the right track, while keeping this aspect of things in mind.
Thread beginning with comment 460209
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[9]: Machine language or C
by Alfman on Sun 30th Jan 2011 09:13 UTC in reply to "RE[8]: Machine language or C"
Alfman
Member since:
2011-01-28

"On the other hand, premature optimization is always a waste. I just can't think of a way to extract a benefit from it."

I am just being a contrarian here for the sake of it, but all too often a business will ship code without any consideration of the efficiency of the contained algorithms. The users inevitably come back complaining about performance, and the ultimate solution ends up with buying new hardware since nobody wants to touch the code.

Arguably, a good programmer, who keeps an eye open for places to optimize, should do so immediately if there is no loss in readability. Programmers who get used to this practice will train themselves to write more efficient code from the start without spending too much time thinking about it.


On the other hand, I found myself in an argument with a CTO at an ex-employer about removing all string concatenation in dotnet web services in favor of string builders. He was totally adamant about this that it became a company wide policy to do all concatenation with a string builder. Presumably he read something about string builder being better somewhere, and he over generalized the point to the extreme.

I submitted a test suite to measure his claims and low and behold, for the vast majority of concatenations he was having us remove, the result actually made things (marginally) worse. So there he is convincing clients we're optimizing the product... He didn't want to loose credibility so his policy stuck, but we didn't get along after that. What a mess.

I hope someone kicks me off my high horse if I ever become so blind.

Reply Parent Score: 1

RE[10]: Machine language or C
by Neolander on Sun 30th Jan 2011 09:25 in reply to "RE[9]: Machine language or C"
Neolander Member since:
2010-03-08

The problem is that although experience can help sometimes, more often than not we don't actually know what is slow in a program before we see it running.

The first time code is written, the primary priority of a developer should not be speed, but cleanness, maintainability, and getting it to work.

Once code is running and working, we can profile it, and see where it spends its time. Afterwards, we can optimize accordingly. Saves a lot of time, and helps keeping the vast majority of the code clean while only putting dirty optimizing tricks in the parts which actually need to be optimized.

Edited 2011-01-30 09:26 UTC

Reply Parent Score: 1

RE[11]: Machine language or C
by Alfman on Sun 30th Jan 2011 09:32 in reply to "RE[10]: Machine language or C"
Alfman Member since:
2011-01-28

"The first time code is written, the primary priority of a developer should not be speed, but cleanness, maintainability, and getting it to work."

I don't disagree with the order of priorities here. But I do believe efficiency should have a larger role up front than your suggesting.

Once the whole thing works, the "cement" has already begun to dry, so to speak.

Reply Parent Score: 1

RE[11]: Machine language or C
by Alfman on Sun 30th Jan 2011 10:00 in reply to "RE[10]: Machine language or C"
Alfman Member since:
2011-01-28

I'll concede the industry consensus is on your side.
Professors preach how premature optimization is bad.
Client contracts generally don't spec out terms for efficiency up front.
Employers never ask about my ability to generate efficient code.
With mores law, who cares if code is less efficient? Ram is cheap, so are more cores.


This collective mindset has lead to code bloat of unimaginable proportions. A desktop with productivity apps require insane amount of ram and cpu for no good reason.

I guess I'm just one of the few dinosaurs left who appreciates the elegance of tight code and I just lash out in vein at what I view to be the cause of it's downfall: the trivialization of optimal code and efficiency.

Edited 2011-01-30 10:01 UTC

Reply Parent Score: 1