"When I started writing programs in the late 80s it was pretty primitive and required a lot of study and skill. I was a young kid doing this stuff, the adults at that time had it even worse and some of them did start in the punch card era. This was back when programmers really had to earn their keep, and us newer generations are losing appreciation for that. A generation or two ago they may have been been better coders than us. More importantly they were better craftsmen, and we need to think about that." I'm no programmer, but I do understand that the current crop of programmers could learn a whole lot from older generations. I'm not going to burn my fingers on if they were better programmers or not, but I do believe they have a far greater understanding of the actual workings of a computer. Does the average 'app developer' have any clue whatsoever about low-level code, let alone something like assembly?
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-10-08
Real programmers don't rely on nebulous optimization that are less optimum, as known from "The Story of Mel, a real programmer". :-)
http://www.pbm.com/~lindahl/mel.html
Member since:2011-01-28
Doc Pain,
"Real programmers don't rely on nebulous optimization that are less optimum, as known from 'The Story of Mel, a real programmer'. :-)"
Haha, it's a fun story. But that sounds more like the manifesto of a defiant programmer than anything having practical value.
Hell, even in intel processor terms I've seen similar patterns, like programmers who relied on the memory wrapping behaviour of the 8086 at the 1M boundary due to the processor's original limit of 20 address lines. It was ridiculous to rely on that quirk, yet some (microsoft) programmers did and consequently there's been a number of hardware hacks to control the A20 address line ever since.
http://www.openwatcom.org/index.php/A20_Line
I do appreciate clever tricks as a form of CS "art", however I kind of hope the employees responsible for the A20 mess were fired over it since it was very irresponsible.
I myself have often cited shortcomings of the GCC optimiser, leaving me to contemplate whether to use non-portable assembly or to use GCC's code as is. In most cases suboptimal code is irrelevant in the scheme of the program so it's not even worth looking at. However in very tight loops such as those in encryption/compression/etc algorithms, hand optimisation can make an observable difference.
In any case, suffice it to say that GCC can handle the multiply by shift/addition on it's own. So my personal preference is to see x*CONST in code.
Is (((x<<1)+x)<<1)+x faster than x*7? I don't know without profiling it. On x86 it'd compile down to two LEA opcodes, which are darn fast. What about (x<<3)-x? Long story short, I'd rather let GCC handle it when it can since it's architecture specific anyway.
Member since:2006-05-20
Thanks, Alfman; very interesting stuff. I must admit that I did not encounter the "x+x+x" issue myself. I *THINK* I heard that story from Herb Sutter and Bjarne Stroustrup at SD West about five years ago, but I could be misremembering. The point remains, however, that you can mis-apply knowledge, even if that knowledge is accurate.
Why does Google get so much credit in the technology industry? Why, despite the company's many obvious failings, do many geeks and enthusiasts still hold a somewhat positive view on the all-knowing technology giant? A specific talk at Google I/O this week provides the answer.
OSNews is a sponsor of this year's O'Reilly OSCON in Portland, Oregon, USA. A lucky OSNews reader will win a free three-day pass, including two tutorials days. To win the pass, post a comment on this story saying something about Open Source Software or OSCON. We'll pick a winner at random next week. If you don't have an OSNews account, you may email us your entry. Part of the conference is the 9th annual Open Source Awards, and today the 16th is the deadline for nominations. If you'd like to nominate an outstanding open source contributor, do it here. Read on for more information about OSCON. Update: The 20% discount code for OSNews readers is "OSN."
"Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening." That's one way to start an insider explanation of why Windows' performance isn't up to snuff. Written by someone who actually contributes code to the Windows NT kernel, the comment on Hacker News, later deleted but reposted with permission on Marc Bevand's blog, paints a very dreary picture of the state of Windows development. The root issue? Think of how Linux is developed, and you'll know the answer.
This is one of those news items that's fun to write, fun to read, fun to comment on, and where no one will be able to say anything unkind. It's all just one big ball of awesome fluffiness. TuneTracker, the BeOS radio automation software, has just released something very special: TuneTracker System 5, the first version designed entirely and specifically for Haiku. In fact, it actually includes Haiku in the software package. Better yet, TuneTracker also unveiled several system-in-a-box products - which have Haiku and TuneTracker pre-installed.
Exactly twenty years ago, a document was published that played a huge role in establishing the web as we know it today. Twenty years later, and this simple and straightforward document is proof of an irrefutable fact: while closed technologies can change markets, open technologies can change the world.
Oh multitasking. That staple of computing that got thrown out the window with many modern smartphones. We got some rudimentary thing in its place - but even as multitasking on phone and tablets improves, its user-visible side remains cumbersome. Windows 8 has a neat implementation, and now it's time Android follows in it footsteps.They're here! Whether that excites you or not remains to be seen, but the Galaxy S4, which will most likely become the best selling Android smartphone of the year by a huge margin, has been reviewed by all the major sites, and there's lots of interesting conclusions in there - although I think most of you will get the gist.Nokia has posted its quarterly results for the first quarter of 2013, and just like the quarters that came before, there's not a whole lot of good news in there. The rise in Lumia sales still can't even dream of making up for the sales drop in Symbian phones, and when broken down in versions, the sales figures for Windows Phone 8 Lumias in particular are very disappointing. In North America, Nokia is getting slaughtered.The day has finally come: Google has started shipping Google Glass to the lucky few early adopters. Now that it's shipping, Google has also unveiled a lot more about the API and the specifications of the device itself. While the company had already given out substantial details at earlier occasions, there are still a few surprises here.
Almost exactly three years ago, I wrote about why OSNews was no longer OSNews: the alternative operating system scene had died, and OSNews, too, had to go with the times and move towards reporting on a new wave of operating systems - mobile, and all the repercussions that the explosion of smartphones and tablets have caused. Still, I was wondering something today: why aren't we seeing alternative operating systems on mobile?
Member since:
2011-01-28
ingraham,
I upvoted your post because I thought it was insightful. However...
"For example, after learning that add instructions are faster than multiply, a developer starts writing 'x+x+x' instead of '3*x' in their code. But adding is not TWICE as fast as multiplying, so he just slowed down his code."
It is silly to manipulate source code to optimise cases that can just as easily be handled by any respectable compiler, but I found your example ironically humorous because I performed this micro benchmark just now, and x+x+x was indeed faster than 3*x on my x86 processor. Only once I reached 4 did it become slower. The fastest solution by far was (x<<1)+x (this can be done in a single opcode on x86 btw).
Edit: Programers should be aware that the compiler already does these optimisations under the hood.
Edited 2012-09-30 04:47 UTC