What is Digg?Sponsored by Travelzoo
Take Advantage of Ridiculously Low Holiday Airfares view!
travelzoo.com - Flights $52 and up for Thanksgiving, Christmas & New Year. But move on it now.
13 Comments
- fyngyrz, on 10/12/2007, -1/+8There have really only been three distinct waves of "application speed and efficiency" since the beginning of the microprocessor-based computer. The reason that it seems to be a continuous process is that unlike CPU speeds, the transitions from wave one to two to three take place at different times depending on which software we're talking about, and the process is made less transparent by the differences between one application's overall coding efficiency and another's; when you first get an application, all you know is "how fast it runs." You're not likely to notice much change because of coding from version to version, most of the time, but you can't avoid noticing when a wave transition takes place because slowdowns and size increases can reach orders of magnitude.
The underlying cause here is the software language technolog(y/ies) and how they are used.
Wave one: Applications that are written in assembler are easily and naturally efficient. You can make them inefficient, but you have to be pretty stupid to do it accidentally. Writing software is like pulling teeth; accordingly, applications are small. In the 1970's, anything serious was written in assembler.
Wave two: Applications written in C generally take much more memory than those written in assembler because there is considerably less efficiency of reuse of processor resources and subroutines, but speed drops less than memory use increases. Writing large applications is moderately difficult, applications are generally moderate in size and complexity. By the late 1980's, a very large proportion of applications were being written in C.
Wave three: Applications written in C++ bring in an entirely new level of inefficiency, again *generally* speaking, because the profligate reuse of objects and new overhead in managing far more complex (internal) structures now consumes large amounts of memory *and* processor time. Because of an increased reliability for re-use of objects created by others, applications complexity regularly reaches levels rarely seen previously. By about 2000, C++ was the "in" language to write in. It remains so today, with a few variations (such as Apple's proprietary objective C.)
All during the time that the potential to take advantage of these transitions became available to software authors, the amount of fast (RAM) memory available for application storage and data manipulation increased steadily, as did long term (hard drive) storage. CPU speeds increased. This is the force that acts to counter the transition from wave to wave; it is, in the end, what forces a consumer to buy a new computer. Watching your neighbor or co-worker's machine do what yours does, only several times faster, is a purchasing motivator unlike any other. Time, after all, may not be money, but it is irreplaceable for us all.
It is important to understand why developers make the transitions between waves. Each wave allows developers to create software with more features, faster; that is, from concept to marketing, the process is more efficient. The cost, that of running slower and consuming more resources less intelligently, is passed on to the consumer. The consumer pays that cost by upgrading their hardware. In this way, hardware and software developers pass downsides along and maximize the upside for themselves. The transactions between them and the consumer are made worthwhile by the potential for additional features and complexity offered by each wave.
So far, we've not really seen a fourth "wave" of software written in a a language derived from, or superior to, C++, but you can be assured that if and when we do, it's unlikely to be any faster unless that speed comes from the underlying hardware, as it always has in the past. The closest we have seen to a fourth wave has been Java, which is a language with many of C++'s advantages, a few of its own, but which unfortunately runs very, very slowly by comparison because unlike assembler (which does not require compilation) and c and C++ (which are only compiled once, by the developer) Java programs pass the cost of compilation along to the consumer, who pays it each time the program is run. Java has been largely restricted to tiny web applications because of this, but we are seeing some efforts such as Open Office that use Java far more extensively.
Another cost that may form part of the fourth wave is a growing movement towards data abstraction into less and less efficient formats (from the viewpoint of what the software has to do to handle it) such as XML. Again, so far, XML hasn't made a huge impact, but it is there and you'll be running slower because of it one day soon, if you have not already experienced this.
We are trading complexity, space, and application power for time. We are recovering time by virtue of improving the hardware.
Interestingly, I know of some companies that have, on principle, refused to transition out of wave two. On has written a public argument for it, here:
http://www.blackbeltsystems.com/wfast.html
There is no "Gates Law." - thinkdifferent, on 10/12/2007, -0/+3Apple seems to be bucking this trend of Gate's Law. Every version of OS X has been faster than the previous version on the same hardware. Upgrading the OS is like getting a new computer due to the speed improvements. The Safari team doesn't let code into the tree unless it is faster than the current build. While there is a natural desire for developers to add more features, it is possible to build that new functionality intelligently so that it doesn't impact performance as substantially as it could.
I think every developer should try to write an app for J2ME. Try building a functional app with a GUI in under 64KB of heap. It really teaches you to think about what you are doing and how to manage resources. Taking what you learn there & applying it to other projects means your code will be tight & clean. - frem001, on 10/12/2007, -0/+3That's true i installed tiger on my old imac g4 (the first ones released) and it was more responsive when using the OS, however upgraded applications didn't react the same way, they became slower. Still a great machine for basic functions like music, light photo editing, light film editing, contacts, word processing, watching films, older games, surfing the web and email. Still works amazingly enough, well considering that the longest i've had a computer for before ***** it up is 2 years.
- fyngyrz, on 10/12/2007, -1/+3I'm terribly sorry to have stressed your reading capabilities. Truly. To make amends, let me help you. I suggest you start reading the sides of cereal boxes, and work up to actual magazine articles. This, like any progressive exercise where the exercise peak exceeds the goal maximum, will prepare you for the enormous stress of taking on my several-hundred word essays. You can do it. Go on. Try. We're rooting for you... soon, you too can join the ranks of the somewhat-literate! Really!!!
- fyngyrz, on 10/12/2007, -1/+3I agree, there have been noticeable speed increases. Unfortunately, there have also been noticeable degradations of functionality; for instance, the Terminal application no longer co-operates properly with remote XTerms. It seems they could be taking a little more care, at least from where I sit.
I'd like to see people program a medium sized application in assembler on a nice orthogonal 8-bit processor (6809 is the best candidate I know of) before we call them "programmers" at all. Until you've done a fair bit of assembler, odds are good you really don't know what's going on at the metal level, and that is the single most crippling thing, speed wise, a programmer can lack. Just because it takes one line in a HLL, doesn't mean it's going to be fast. You have to know how computers *actually* work underneath, and what compilers *actually* do, to write the best quality, highest performance code.
But... that's just me. :-) - dtfinch, on 10/12/2007, -0/+2It's sad when your text editor scrolls at a slower fps than most realtime raytracing demos can render.
- fyngyrz, on 10/12/2007, -1/+3Some of that is on target, except the first bit and last bit.
First bit: Your idea of assembly gaining "five seconds instead of ten" is highly unrealistic. Typical gains from assembler to C++ would be much, much higher. It depends on the job at hand, but gains that are orders of magnitude are not by any means unlikely.
Even gains from C to C++ can buy you 4 to ten times simply by eliminating C++'s enormous weight of computational baggage. A nice practical example is WinImages compared to Photoshop; WinImages has far more features, is WAY way faster, and weighs in at four megabytes, including DLLs and plug-ins. WinImages is written in C. Photoshop 7 (the latest version I own) is twenty five megabytes, including DLLS but not including plug-ins. WinImages picks up twenty megs of working memory for images, brushes, plug-ins and so on, starts five times faster at a *minimum* by load time, though really it starts much faster than that because it is much quicker to register plug-ins and otherwise get it's poop in a group so you can work. Consequently, WinImages can run in a far tighter environment, memory wise, and it can run effectively in a far slower machine. These are all differences that accrue because of the technological choice to go with wave two.
Last bit: If Moore's law benefits the C++ user, it benefits the assembly programmer as well. There is no win here.
For example, let's say that the C++ effort has a relative speed of 5 to start with, and the assembler has a relative speed of 50, all on the same hardware. That's ultra-conservative, just ten times. Now hardware comes along that confers a speed multiplier of 25 over the development time of the two projects. The C++ project is now running faster than the assembler project *would* have been, as 125 (25 * 5) is certainly faster than fifty. However, the assembler project is now running at 1,250 (25 * 50), still ten times faster than the C++ project. So it is VERY clear that once you accept a speed degradation by moving forward a wave, you cannot ever get that degradation back on a competitive basis. You have to compete on the actual, available benefits, which are (1) faster development time, (2) the ability to use the newly free time to debug, add new features, get to market sooner. These are very real benefits, but they don't replace the speed advantages.
In a project where you are not compute bound (an office suite being the poster child for this), you'd be out of your mind to use assembler. However, using C is something an argument can be made for, because among the disadvantages of C++ are the accrual of object-encapsulated errors you cannot fix because you don't have the code for them. For instance, Microsoft's treeview control is buggy. If you use it, you buy the errors. Microsoft's file dialog is *also* buggy. If you use it, you incur all of those bugs as well, and you can't fix them, either. So, in return for the speed and power, you get trouble. If, on the other hand, you avoid embedding other people's objects -- or you can't, as is the case with C, at least, you can't do it easily -- then you obtain control of these problems.
In cases where you *are* compute bound, such as graphics, special effects, animation, sound processing... it's not a bad idea at all to look at the project and see if you might be better off throwing C++ out the window and (at least) going back to c. Some things -- such as CPU emulation -- should send you right back to assembler. But those, admittedly, are quite rare. And it is important to realize that although C is not an "object oriented language", implementing objects in C is not only possible, it is easy and so when working that way is desired, you just "do it." Because you "just" get the objects, and not all the rest of the OO paradigm, they remain lightweight and do not incur the same computational costs as does working in actual C++. - soupnazi, on 10/12/2007, -1/+2Very well thought out comment. But blackbeltsystems seems to be the exception, not the rule. The temptation for feature bloat and incorporation of new technology (XML et. al) is simply irresistible to most software.
- kyriakos, on 10/12/2007, -0/+1Imagine how long the development of an office suite with today's features would take in assembler .. now assuming that you are crazy enough to complete such a project would the outcome really be better than what MS Office or Openoffice are today? Will it be faster? Let's say it is faster and recalculates your spreadsheet a second earlier or manages to print your 100 page document in 5 seconds instead of 10, does it really matter?
Assume a competitor started developing at the same time when u started developing your suite in assember, a similar product with the same features but he's using C++ under windows or maxosx or linux or any current operating system. Everyone will agree that it would take your competitor a fraction of the time.
Now considering how long the development in assembler would take you by the time you have it ready moore's law would have produced 2-3 times faster hardware that would actually get your competitor's software to run at the same speed as yours would have if it was completed in time. Your competitor had a few years more time than you to market his product meaning you are just too late for it to sell. And by that time your competitor would have planned and maybe already developed his new version. - fyngyrz, on 10/12/2007, -2/+2Thank you for your kind words. I mentioned BBS here because this is not only one of the very few exceptions, but because there is actually a little discussion of of the underlying issues. I've known those people very, very well for many years. "Think Different" is an understatement. It's like being around Klingons. Really cool Klingons, but still... Klingons. :)
- echoic, on 10/12/2007, -0/+0Wow, way to leave out C# though Java does illustrate a fourth and much slower wave. Though it still isn't capiable of leaving as small a footprint as it's namesake it has been used to code efficent and stable realtime applications like the MMORPG Ultima Online Emulator, which if you've ever done any game programming isn't easy to begin with much less making it stable in a largely unmanaged language.
- 1111, on 10/12/2007, -1/+0"nop" for the loss
- unitedstatians, on 10/12/2007, -4/+2Noooooooooo looong comments belong on http://www.slashdot.org not on digg
The Digg Toolbar for Firefox lets you Digg, submit content, and keep track of Digg even when you're not on the Digg site. Download the official 
© Digg Inc. 2009
— Content created and posted by Digg users is