Say Hello to X64 Assembly Part 3

Re:Say Hello to X64 Assembly Part 3 by radmuzom on Friday September 19, 2014 @05:26PM (#8342584)

Even though I don't advocate application programmers using assembly, I strongly disagree with your statement "Even interpreted langs seem fast enough these days". This is true probably for a small subset of programmers who are mostly into web programming (and using the logic that network and not the CPU is the bottleneck which is plain nonsense), but not true for programmers who create useful applications used by many companies around the world. To give some examples not necessarily related to interpreted languages but to show how fast software is getting worse and worse, 1. My Windows 2000 start-up time on a 1GB machine was probably slightly higher (4-5 seconds) than Windows 8 start-up time in a 8GB machine. It looks like improvements in hardware have not made any difference to the user experience. Similar for Linux, but that may be driven by distributions bundling more things at start-up. 2. In Excel 2003, I could right-click on a cell and format - the formatting dialogue would open up instantly. In Excel 2010, I need to wait 2-3 seconds for the dialogue to open up. 3. I regularly use software like TOAD and SAS at work. Given that both are often used to examine data, I need them to work very smoothly after they have retrieved the necessary data from the back-end database. TOAD is ok, but SAS has gotten progressively worse over the years. I don't care whether your developer time is costlier than compiler time, I need the software to work as fast as it can only constrained by the specifications of my machine. 4. Laptop at work is encrypted using Symantec products. The software is so bad that the hard disk light on the laptop just keeps on "glowing", indicating HD activity, continuously without EVER stopping. All applications are slowed down too because of this activity.

I could just go on and on about how software is getting worse day by day. Even John Carmack recently tweeted about this - how smartphones with massive processing power and small resolutions can't display graphics decently as compared to very old machines. Anyway, thanks for letting me vent out my frustration which has been building up for quite a few days now.

[ Parent | on HN ]

Re:Say Hello to X64 Assembly Part 3 by userbinator on Saturday September 20, 2014 @03:30AM (#8343948)

I don't care whether your developer time is costlier than compiler time, I need the software to work as fast as it can only constrained by the specifications of my machine.

I can't agree more. Many programmers are traditionally taught that optimisation is some sort of "last moment" effort for when thing are seriously bloated and slow and that programmer time is more expensive than machine time, and it seems all this does is breed a lazy, selfish attitude; yes, it's very likely not worth expending an hour or even 10 minutes to optimise a throwaway script that's used by yourself and isn't a bottleneck in your process, but when your software is used by hundreds, thousands, or even millions or more users worldwide, who are often paying users, it doesn't seem nice at all to be making them all wait or be forced to buy newer hardware just so you can "save" a bit of work that you should be doing anyway.

It's like http://xkcd.com/1205/ , multiplied by the size of the userbase.

[ Parent | on HN ]

Re:Say Hello to X64 Assembly Part 3 by cnvogel on Saturday September 20, 2014 @04:50AM (#8344058)

I feel your pain, though the first two things you mention will never be improved by vigorous application of assembly code in software, and actually I'm a big fan of interpreted/scripting languages.

E.g. your start-up time of Win 8.1 compared to Win 2000 on the two quoted machines probably will not change more than +/- a few percent if you'd change from completely-unoptimized-compiled C, to hyper-unrolled-handtuned-SSE3-AVX-assembly.

Also the quoted few-second delay of MS-Office popping up the "Cell Format" dialog probably has more to do with the software asking (I'm making that up) the OS for a list of 1000 fonts and their properties, and less with MS Excel being written in optimized assembly, C, VBS or python, for that matter.

In my experience, some programmers like to discuss endlessly about the merits of replacing "i4" with "i<<2", or other stupid micro-optimizations[#], and are often completely oblivious about the "high-level" design, such as using proper data structures or how to schedule their work efficiently on multiple cores. And, for the "high level" issues, scripting languages might even help coding out larger systems quickly, so that more proper optimization effort can be spend on the actual computing intensive or resource hungry task.

[#] THIS IS JUST A STUPID EXAMPLE! DON'T DISCUSS i<<2 <-> i4 HERE, PLEASE!

[ Parent | on HN ]