I don’t think Chronos was saying software bloat has nullified all hardware advances (I read his comments as a little hyperbolic and not to be taken completely literally in all cases), just that it’s a trend. Which it is.
Typically it’s a pragmatic choice, trade-off compute resources for man-power to rewrite something because man-power is more expensive.
they haven’t been “nullified.” They’ve been made use of. Yes, I know Netscape 1.0 could run on a system with 8 MB of RAM, but it was expected to do little more than arrange text and links on a gray background. Modern webpages use computationally expensive things like animations and javascript to do useful stuff, and old browsers can’t render that (and modern browsers on old systems choke to death trying.) I have 16 GB of RAM in my system. It’s there to be used. I don’t give a rip if Chrome is sucking up a few hundred MB. If something else eventually needs it, I’ll either quit the browser or the OS will make room.
it’s a myth that rewriting code makes it faster. Look at the disaster that was Netscape 6.0.
Hardware advances happen because it’s the nature of the industry. Expecting that software developers will decline to make use of those advances is silly. I don’t have a quad-core CPU and gigabytes of RAM just so it can sit there 90% empty.
Have you never seen software bloat in person?
I’ve seen it and I’ve contributed to it many many times.
It happens, trust me.
Sometimes rewriting software makes it faster.
Sometimes rewriting software doesn’t make it faster.
HAHA. I wish. I timed my work computer as it rebooted the other day (a Core 2 duo). No updates. It took 7.5 minutes to restart and get to a usable desktop (includes about 15 seconds for me to log on).
That doesn’t necessarily make sense, unless that code was perfectly optimized to begin with. It’s not necessarily the same sort of code, but I can’t count the number of database queries that were either written with older versions of SQL or that weren’t really written that well to begin with that have been drastically improved by rewriting. I imagine the same thing goes for other sorts of code as well- hell, hardware improvements and new instructions would in many cases warrant a rewrite just based on those alone.
What computer/OS/permanent storage medium do you have?
When I read your comment, I decided to time my restart process. I’m on a 2-year-old Macbook Air running OS X 10.6.8 with a Core 2 Duo and SSD, from the moment I hit the power button to restart:
20.7 seconds to close everything down (I had about a dozen programs running at the time)
12.9 seconds from that point to a login screen.
13.0 seconds from that point to seeing a desktop (and I mistyped my password the first time. It’s only about 3 seconds from having my info typed in to hitting the desktop)
21.4 seconds to have Chrome loaded with this page up (and the other dozen pages I had open).
My impression is that it’s often faster than that and sometimes slower (when there are updates, a lot slower), but I’ve never tested it before, and focused on the timing, so I could be way off. Certainly, some reboots don’t take as long to shut down because I’m not running much at the time. Still, this time I was back to doing what I had been doing in less than a minute and a half. That’s a huge improvement over the past.
Kind of curious what other people see. Should I start a separate thread on this?
Is this how framerates are dynamically adjusted? But doesn’t that mean it has to finish drawing a frame before it can adjust i.e. framerate will be 1 frame behind?
It depends a little, there’s two ways you could do framerate:
Calculate the current framerate and draw it with the rest of the scene as an overlay. In this case the framerate will tell you the framerate as of the PREVIOUS scene.
Render the scene, calculate the framerate, and then render the framerate number on top of the scene (rendering a 1-3 digit number is very cheap, as is calculating framerate, so the time it takes to do this is negligible). In this case, the framerate is current.
I’m not sure which one is more common, most likely 2 since it is more accurate and simple to set up if you have a halfway decent rendering pipeline, but I’m sure 1 has been done.
Missed edit:
It also depends for 1 whether the framerate calculation is done after the update cycle, during it, or at the end of the previous render cycle. In the first case, the framerate will not be sensitive to a GPU or shader problems (or rather, it will be behind in sensing GPU problems), but will be sensitive to a CPU problem. The latter two aren’t going to produce accurate information if the framerate crashes for some reason.
Granted, in most cases it probably won’t matter much, but there are numerous cases where it could (which, incidentally, are probably most of the cases where you’d want a framerate count anyway).
IME, the best (worst) example of this is WinAmp. What used to be a tiny, efficient program for playing music became a huge bloated program with skins that wanted to play movies and do all kinds of other things. I actually haven’t tried to use it in years, when it used to be one of the first programs that I installed on a new PC load.
I did a tiny bit of research for this response, since I haven’t used it in years. According to Winamp - Download Old Versions for Windows WinAmp 2.95 (2.4 MB) is the most popular version. The latest version is 5.623 (15.71 MB). The oldest version is WinAmp 0.20 (.2 MB).
See? This is precisely my point: They added functionality you personally don’t want, which you interpret as bloat. To someone else, the video playing functionality is the point, and the stuff you use is the bloat.
This doesn’t actually answer the question I asked, though. Yes, WinAmp is larger in terms of program size. Yes, WinAmp has more features. But you don’t have to use WinAmp; foobar2000 is a far superior music-playing option for Windows which most certainly does more things in less time than WinAmp on a 1998 computer did. WinAmp being crappier than it used to be does not mean that “you can’t use [modern hardware capabilities], since it’s all bloated away”.
Looking at a single application is very misleading, though. A single application is almost always going to increase in size and features, since that’s the way to sell more copies. Brand new applications, on the other hand, are usually going to start out with a very minimal feature set, because it takes time to add features.
You can see the same kind of progression in cars. Look at almost any single car model over the years, and it gets bigger, heavier, and higher performance with each redesign. But the trend among all cars may do something quite different, since newer models are introduced on the low end all the time.
The other thing that causes software “bloat” is using frameworks that make development easier. Yes, I could write my own GUI library that includes just the stuff I care about, or I could make use of one that someone else has written, that maybe includes a bunch of stuff I don’t need, but saves many hours of work. Disk space and memory are incredibly cheap compared to software developer billable hours, so it simply doesn’t make sense to spend a bunch of time optimizing for them.
Not so. I have an old copy of Championship Manager 3 (released in 1999 and designed to run on Win 95 machines) which runs so fast on my Win XP machine that I have to increase the mouse click delay to play it or it registers every click three times.
Windows Solitaire (first appeared in MS-Windows 3.0) was for a long time an infamous example of a program that didn’t adapt to faster computers. But mainly for the post-win flourish of bearing the cards off the window. As computers got faster, the flourish got faster and faster until it became an eyeblink sort of think. I don’t know what OS/version finally fixed it, but for a while it’s been a standardized speed. (BTW, it’s not included with MS-Windows 8. It’s a separate download.)
It was an interesting demo of how fast a computer was, seeing the cards bear off. But you had to play a winning game first.
My own experience with manually timed games back in the day was the limited choice. I had a 10MHz XT clone, which was a bit faster than a standard XT and so games ran too fast and there was never an option for that speed.
There were memory-resident programs you could install (like “Whoa”, got it at Simtel!) that would eat up a settable number of cycles and slow things down. But the switching back and forth between the game and the program caused stuttering effects.
It often depends on what else is set to load up with the initial start up of the machine. Including a bunch of stuff like the Google Desktop Toolbar or anti-virus programs can drastically increase the time to do an initial boot.
For example, my work laptop (HP with a intel i5 M520@2.4 ghz and 3gb of ram) takes between 10 and 15 minutes to start up from a cold boot. But this is because of the multitude of start-up programs the company’s IT team has insisted on installing and which I have no control over.
By contrast, I have a i7-based HP laptop at home with 4gb of ram (so better, but not by much) that only takes 30-60 seconds to do a cold boot. And that’s because I’ve kept it pretty clean of start-up nonsense.
It really depends on how you have your machine configured, even from the initial purchase since Dell, HP and other companies love to pack in “extra” programs that are demos and other nonsense with their builds.
This is my issue. I am running slightly older hardware and my system is loaded to the gills with hyperactive security software installed by our IT. They don’t really care if it slows everything down, our productivity is not their concern.
We also have a really terrible program that interfaces with our Voip phones and is essentially an instant messaging program and an electronic rolodex. It starts up using about 200MB of memory, but I have seen it grow up to 950MB on my machine. Considering that my machine only has 2GB of memory, this puts a serious dent in performance. My HD starts thrashing all over the place. Bloat for the win!
that’s not “bloat,” that’s a memory leak.
That’s why I added my addendum in another post. As I said, it was a quick answer to illustrate the basic concept. I do thank you for elaborating on my second post, however.
BTW, as I pointed out, there’s usually a lower limit for frame rates, beyond which the game does indeed start running slower. I described an example.