newb questions, hit the hardware or not?

[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."

[biggun]

you're talking nonsense.

"Bull.

"what an asshøle."

How about we try to stay calm and behave?
Maybe we could even go back to the main topic?


I think the main question was is going directly onto the hardware OK?
And I think we can agree that this is OK - as long as one is aware that running on OS4 machines is then not working.

One think is clear and everybody will agree to this.
Coding in high level languages is easier.
Coding complex routines in ASM takes more time.

[guest11527]

Bull.

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

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.

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

Maybe I'm an ass, but maybe an ass with a little more years behind me. Get older, learn more. As soon as you've done some larger real software, we talk again in years. Either, you're no longer in the business, or you've learned how it works.

[psxphill]

Low-level optimization does not prevent you from doing high-level optimization

It does not completely prevent you from doing it, but writing complex code in assembler is a lot harder than writing it in C#/Java because you have to do everything yourself.
 
I've replaced assembler with C in projects that has ended up with the C code being quicker, it was rewritten in C to make it portable but in the process I noticed simple ways to optimise the algorithm. The effort required to optimise the assembler code wasn't worth it, neither was writing another version of it for a different assembler.
 

(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.)

It's not a myth. It's much easier to spot bugs in a high level language than it is to spot one in assembler. If you have infinite time to study a small assembler program then yes you can get it to zero bugs & sometimes that is important. Time pressure usually means that if you can't spot a bug by speed skimming your code as it scrolls by then it's likely to ship. Automated testing and code analysis also helps reduce bugs, but again these are easier to do with high level languages than assembler.
 
I guess you have never had to spend a couple of months writing 400 lines of code a day to have it tested for a couple of days before it's deployed to thousands of users who work outside of office hours. You need that to work. Language doesn't give you it magically, but spending the time to evaluate whether you could do it faster in assembler is likely to break your budget.
 
Having the same source compiled for PPC and 68k is more important than shaving off a few microseconds. Even if you could speed layer operations up by a further 10%, it would only make a noticeable difference if software was constantly performing layer operations. If it was doing anything else then it will diminish the return you get.
 
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. It would be cheaper to phone up Motorola and pay them to design a faster 68k just for you.

[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.

[guest11527]

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.

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?

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? Otherwise, I'd say you'd better stick with the free version you got, and stop complaining about a couple of irrelevant micro-optimizations the compiler missed.

[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.

[Thorham]

I'll stick with assembly language on my A1200, because it's one of my computer related hobbies, and I'm certainly not going to have some bloated ego tell me it's a waste of time.

[psxphill]

I just take exception to your claims that using assembler is never relevant.

I've only seen that he is taking exception to criticism that he hasn't written it in assembler, with people justifying themselves by saying it's a myth that writing in assembler takes longer and is more error prone.
 

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.

His argument appears to be: Before you do any optimization you should determine how much time the code is actually running for. In this circumstance he believes it doesn't run often enough that writing it in assembler would have any noticeable effect. This goes for any change that increases the on going maintenance cost. Sometimes optimising an algorithm in C has no visible benefits because it's not called often enough and it's more cost effective to throw away the optimised version.

[Thorham]

with people justifying themselves by saying it's a myth that writing in assembler takes longer and is more error prone.

Who the hell ever said that? Of course it takes longer and is easier to mess up (doesn't mean you end up with bug riddled code, like someone claimed).

[guest11527]

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.

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. Layers does not have such bottlenecks. The only bottleneck is the memory copy for moving data around, and that *is* already in assembly (though not part of layers).

Thus, if you see any delay in depth arrangements or window movements, these delays cannot be resolved by changing the code to assembly or using irrelevant modifications from lea to move. It won't make any freaking difference. It would make a difference to get rid of the Zorro bottleneck, but that's beyond what you can reach with software.

The bottleneck is known, and approached as good as possible: By *avoiding* such slow operations whenever there is a chance to. That's an algorithmic improvement, and no, it does not take any bit of assembly to make it happen. It would have been much harder to improve the code in the same way if it would have been assembly, actually.

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. The problem remains at 5% of the code, and if that 5% is already optimal for the case at hand, there are no chances to make anything any better.

[Sean Cunningham]

...Sometimes optimising an algorithm in C has no visible benefits because it's not called often enough and it's more cost effective to throw away the optimised version.

Your name made me recall the first generation of next-gen consoles and how they relate directly to this discussion.  The developers on the original PSX titles were coding games in C and couldn't achieve anything but porkish performance and absolutely nothing for the first couple generations could achieve anything approaching arcade quality responsiveness and framerates.  

Over at SEGA, in particular their AM divisions, they were coding for the Saturn "close to the metal" and could actually achieve arcade feel with arguably less power (if you weren't fully taking advantage of its multi-processor design, and most 3rd parties weren't really up for this kind of complexity, just like they weren't for a long time with the PS3 and virtually any other multi-processor design).  

The Saturn didn't have the true 3D acceleration that the PSX had but the Sony developers made it swim through a pool of peanut butter by coding the games the way they did.  At the resolutions those titles were working at the Sony games should have been 30-60fps out of the gate with no lag and that was definitely not the standard.

It cracks me up that all this time there's any room for discussion over how to get the best performance on an Amiga (or any system that doesn't just have excess horsepower to subsidize generic coding methodologies, which relates to my dislike for X-Windows).  The highest performance apps, highest performance games, highest performance demos all speak to the truth of you not getting there through the OS.  Where are these high performance applications that were coded through the OS, particularly with respect to graphics effects, realtime or other forms of manipulation?

[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.

[Leffmann]

I'll stick with assembly language on my A1200, because it's one of my computer related hobbies, and I'm certainly not going to have some bloated ego tell me it's a waste of time.

That's a bit over the top he's perfectly merited to be this assertive, and he is right in what he says - there are no gains to be gotten from withering away doing micro-optimizations on parts that have little or no bearing on the performance of the program.

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.

He's not trying to teach you maths, he's just stating the simple fact that if you for some inexplicable reason choose to optimize a part of your code that accounts for 5% of your execution time, then you can never get more than a 5% performance gain.

[matthey]

Who the hell ever said that? Of course it takes longer and is easier to mess up (doesn't mean you end up with bug riddled code, like someone claimed).

It doesn't mean algorithms can't be improved in assembler either (even if ThoR considers them worthless micro-optimizations also). There are high level algorithm improvements that are generally easier in high level languages and low level algorithm improvements that high level languages may make difficult to see or implement because of abstraction. Assembler is complete freedom, it's just that most people don't know what to do with it. It requires logical and organized thinking to create good code. It's like a puzzle with beauty in the simplest and most logical code. A time schedule would take away from the creative freedom though. Some people have to code for a living and that's why we should try to improve the assembler in compilers for those imprisoned souls .

Algorithms can require assumptions that change also. New fpga Amiga chipsets may have a blitter much faster than the CPU with faster memory again. Perhaps SmartRefresh should be selected for the chipset and SimpleRefresh for a gfx board. Maybe layers should query the gfx system for the best refresh method to use for a gfx mode. There is all that algorithm work fishing for the big fish and that can all become outdated if the "best" algorithm becomes obsolete. At least thousands of micro-optimizations can be applied with quick compiler switches over and over again, provided they are used. Personally, I like tuna and sardines. I prefer to be a little more open minded than 640kB of memory with perfect algorithms is enough for everyone. Isn't it really the time saved compared to the amount of work? I would think that optimizing compilers so that a compiler switch can be used would be efficient in processing time saved vs programming time spent even if it was a few percent of savings. Of course, I'm not a professional programmer so my opinion doesn't seem to count, according to some people.

[Thorham]

That's a bit over the top he's perfectly merited to be this assertive, and he is right in what he says

No, he's not, because he's saying assembly language is a waste of time. To me, my hobby is NOT a waste of time, thank you very much. It would be a different story if he said that it's a waste of time for himself, but he acts as if it's a waste of time for everyone.

- there are no gains to be gotten from withering away doing micro-optimizations on parts that have little or no bearing on the performance of the program.

Obviously. It's just that when you write everything in assembler from the start (hobby!), you wouldn't write compiler style crap in the first place.

It's like a puzzle with beauty in the simplest and most logical code.

Indeed

Some people have to code for a living

Fortunately I don't