newb questions, hit the hardware or not?

[commodorejohn]

You seem to have misread the "algorithm first, implementation later" rule of optimization as "algorithm first, implementation never, also you're stupid and horrible for thinking that a human being could ever be smarter than a piece of software engineered by human beings, or that multiple small numbers can add up into a larger number!" there, Thomas.

[commodorejohn]

Please get your math fixed. If you have n algorithms, each of them spends 1/nth of the time in solving a problem, and each of them is speed up by 10%, the overall speedup is still 10%. In fact, if you only speed up one of them (e.g. layers) by 10%, the overall improvement is much smaller, depending on n, and even marginal.

Yes, obviously. But: on a platform with a bus speed of less than 8MHz, 10% can make the difference between having enough time to get everything done in one frame or suffering a reduction in framerate. It doesn't matter how big or small of a percentage it is, it's the practical impact that matters.

If, however, you have an algorithm whose running time grows as O(N^2) (N being the number of layers being moved, arranged or resized) and that is replaced by an O(N) algorithm (as it happened, actually), then even for suitably small N the improvement can be enormous. It is really that simple. Do not waste your time optimizing the useless details. Get the big picture correct. Then, if performance is still not right, check whether the problem is, find the bottlenecks, and either get rid of them by changing the algorithm, or optimize only there.

Nobody's arguing that algorithmic optimization shouldn't be the first resort, or that it doesn't have much greater potential for performance increases. Of course that's true; it's so well known to be the case that everybody but you is taking it as a given. But that in no way makes the question of whether good code is being generated "useless details." You can't come up with an infinite series of successive algorithmic optimizations - eventually you're going to hit the optimal algorithm for the particular application and platform, and if that's not enough, no amount of casting about for better, purer Ideas will get you any further; you either have to get down and dirty with the low-level stuff, or give up on making it work. Cycles count, no matter how much you want to pretend that isn't the case - if that weren't true, there would be no difference between my Amiga 1200 and my Core 2 Duo laptop other than the quality of their algorithms.

[commodorejohn]

Thus, do you think a 10% improvement in micro-optimizations would make a difference? I can tell you my answer: I don't care.

Then why are you getting so worked up about it?

[commodorejohn]

If any of you cycle-counters had layers (or  any other component of the Os, for that matter) under your fingers, you  would probably replace leas by moves or vice versa, probably gain some  minor improvement, though the project would still not be done, would be  bug ridden by using assembly, and you would have lost the real  opportunities for optimization because you would have not been able to  work on the necessary level of abstraction.

That's not even remotely how that works. Low-level optimization does not  prevent you from doing high-level optimization (and the idea that  assembly is more prone to bugs than high-level languages is a myth. Bugs  come from sloppy thinking, not from lack of language features.)

Except that, in case you really want such a  thing, you'd probably better off nowadays with a couple of lines in  javascript and run it in a browser. (-; Yes, times changed.

No they haven't.

You haven't worked in professional software development, have you?

I have - and you're talking nonsense.

Such projects iterate, are under flux, change, several algorithms are tried, benchmarked, debugged. You cannot do that efficiently in assembly.

Bull.

Probably because I'm a bit longer in the business than you are? It's called experience. It comes over time.

As the canonical New Yorker cartoon caption says, "Christ, what an asshøle."

[commodorejohn]

So, quite frankly, you haven't. Because that's how real projects look like. It's not "here are the specs, start coding today, be ready next Tuesday". It's more like: Here's what we want, we come back in a month, see what we got, here's a list of changes, here's what we want too, here's what we do not need anymore, please iterate on what you did two years ago. That's real life. And sorry, assembler does not work well. It's something that comes, at the very least, at the very end of the project. Been there, done that.

Or, in other words, "anything that doesn't fit within my sphere of experience doesn't count."

Well, anyhow. If you say you've done professional software, may I ask for whom? Who paid, and what was the project?

I do backend-processing development for a call center whose business model is based around delivering captured data in arbitrary, client-specified formats. No, I don't do it in assembler, but it's not a shop where management gets anal about methodology; the goal is to deliver what the clients want in a way that's not too much of a drain on our systems, not to check the boxes that will make us the Purest and Holiest programmers who are removed from such earthy and abhorr'd concerns as how the code actually runs on real machines.

But since that doesn't fit with the point you want to make, I fully expect to be told "that's not professional," even though it's my job and I get paid for it.

If your argument is that every single piece of  software ever written should be micro-optimised, then you're likely to  be dead before any of the software is finished.

That was never what I was arguing. I was simply saying that the fact that algorithm optimization should come first doesn't make low-level optimization irrelevant.

[commodorejohn]

Now, there you go. Why don't you approach your clients like you did approach me, tell them that you could get their software a couple of ms faster by writing it in assembler, and probably take 10 times the time to debug it and get it running? Why not? Oh, probably because that's impractical and you wouldn't get paid? Then, once again, why do you claim otherwise here?

Gee, I dunno, maybe because that was never what I told you? The time saved doing a process that runs once per day on a multi-gigaherz system in assembler is not worth the bother, I agree. (But I wouldn't not get paid, because our clients don't know and don't care what I'm writing it in, as long as they get results.)

But claiming that it's across-the-board irrelevant everywhere, and especially that it's irrelevant in systems where the maximum clock speed, ever, is 100 MHz, and the average is much more likely to be in the 7-25MHz range, is absurd.

Assembler is *not* a practical language to develop projects. If you believe otherwise, I'm happy to offer a project for you. I know how to write 68K assembler. I'm happy to write a 68K assembler version of layers just for you, provided you pay. Estimated development time approximately two month. Given my typical development rates, that's a couple of thousand Euros. Is that acceptable for you?

No, because I don't care about layers at all, I just take exception to your claims that using assembler is never relevant.

[commodorejohn]

Once again: Assembler is pretty much irrelevant, *unless* you can detect a bottleneck somewhere in the code that cannot be resolved by a better algorithm. I believe I stated this before, and I stand to my opinion.

And again, absolutely nobody is saying algorithm optimization shouldn't come first.

Whether 3Ghz or 25Mhz makes no difference to the argument: If 90% of execution time is spend in 5% of the code, optimizing the remaining 95% from C to assembly will not make a freaking difference, regardless of whether the system runs at 25Mhz, 3Ghz or 1.7Mhz.

That's not how math works. 5% at 3GHz is 150,000,000 cycles per second of execution; saving a few dozen here and there is indeed pretty much irrelevant. 5% at 25MHz is 1,250,000 cycles per second - also pretty hefty, but depending on how many iterations of whatever code you're optimizing are running in that time, cycle-shaving can still make a bit of a difference. But at 7MHz? That's but 350,000 cycles - on a system where even basic instructions can take 8-20ish cycles to complete, that can get frittered away a lot faster than you'd think.

[commodorejohn]

Peecee operating system in assembly language: http://www.menuetos.net.

No, no, no, Thorham! You can't manage a large-scale project in assembler, therefore that doesn't exist!

[commodorejohn]

That sounds unmanageable to me, you seem to be confused between something being unmanageable and something existing. I'll give you the benefit of the doubt that you just don't understand the meaning of words rather than trying to bend the meaning on purpose

And I'll give you the benefit of the doubt and assume that you're a robot from space who does not understand the thing we hu-mans refer to as a "joke."