Wise rule says "Don't tweak efficiency until needed". Since we have fast CPUs/GPUs and faster are made very often tweaking efficiency is less needed. I think this rule is sometimes overused, but what can I do? :P
Anyway, there are still people that know much about internals even if they don't use it at work. :) Currently I code in Perl and can tell you something even about pageing internals. By the way we had quite nice class on it on university. :)
1) My problem with this attitude is it leads to, as gaius said elsewhere in this thread[1], "requiring a 2Ghz quad-core with 8G RAM to edit a simple document". Developers should not be relying on improvements to their users' hardware to boost their software's performance, at all.
2) My (soon to be former) work is in signal processing software for military applications. Our customers do not want to buy and upgrade hardware just because some new algorithms don't fit. This creates a situation like the console world (as klez mentioned in his reply) and the mobile device world, where hardware is basically fixed for some period of time for a given user. You have to pay attention to the efficiency of code in these circumstances if you want to expand the capabilities of your applications in any meaningful way.
> Wise rule says "Don't tweak efficiency until needed". Since we have fast CPUs/GPUs and faster are made very often tweaking efficiency is less needed.
In the console world the author is leaving in, hardware iterations are usually slow.
As an example take Tekken 2 vs. Tekken 3 and notice the difference in the graphics. Same hardware (PSX), better software.
Comments
Wise rule says "Don't tweak efficiency until needed". Since we have fast CPUs/GPUs and faster are made very often tweaking efficiency is less needed. I think this rule is sometimes overused, but what can I do? :P Anyway, there are still people that know much about internals even if they don't use it at work. :) Currently I code in Perl and can tell you something even about pageing internals. By the way we had quite nice class on it on university. :)
1) My problem with this attitude is it leads to, as gaius said elsewhere in this thread[1], "requiring a 2Ghz quad-core with 8G RAM to edit a simple document". Developers should not be relying on improvements to their users' hardware to boost their software's performance, at all.
2) My (soon to be former) work is in signal processing software for military applications. Our customers do not want to buy and upgrade hardware just because some new algorithms don't fit. This creates a situation like the console world (as klez mentioned in his reply) and the mobile device world, where hardware is basically fixed for some period of time for a given user. You have to pay attention to the efficiency of code in these circumstances if you want to expand the capabilities of your applications in any meaningful way.
[1] http://news.ycombinator.com/item?id=3827096
> Wise rule says "Don't tweak efficiency until needed". Since we have fast CPUs/GPUs and faster are made very often tweaking efficiency is less needed.
In the console world the author is leaving in, hardware iterations are usually slow. As an example take Tekken 2 vs. Tekken 3 and notice the difference in the graphics. Same hardware (PSX), better software.
Assuming you aren't on a machine with a limited CPU and limited battery power - like a phone.
C++ is making a big comeback where instructions/joule matters