GNU Assembler Patches Sent Out For Optimizing The Intel Jump Conditional Code Erratum

[NotMine999]

When bugs nowadays are sensitive to byte boundaries, don't you wish you had learned to program in assembly and understand complex internal computer memory structures?

Oh wait... learning the details ain't kewl for k0d3r k1d5 in today's world. Dat stuff is the job of the compiler cuz details get in the way of playing [whatever] or toking [whatever].

I guess some of those old gray neckbeard types really did know what they were doing.

[starshipeleven]

I read elsewhere that Intel estimates up to 4% performance drop.

*some workloads are worse

Also please remember that we are talking of a company whose official TDP number has been an elaborate fiction for decades.

[starshipeleven]

When bugs nowadays are sensitive to byte boundaries, don't you wish you had learned to program in assembly and understand complex internal computer memory structures?

No, because fixing hardware problems is not the programmer's job.

Knowing assembly and understand internal computer memory structures is a skill necessary only for micro optimizations, but most software does not need that.

I guess some of those old gray neckbeard types really did know what they were doing.

Yeah, the ones that decided to abandon assembler did.

[log0]

Well it depends how big portion of the code is no-ops. If a significant portion is, then it will unnecessarily occupy room in the cache, slowing down execution.

From what i see it is mostly a couple of bytes per certain branch/jump. For a significant portion your code would have to be full of branches which would run like shit anyway.

[log0]

Branches, right? Not branch targets, then? If so, how can you say extra nops won't affect performance?

I read elsewhere that Intel estimates up to 4% performance drop.

Because the number of nops should be insignificant in most cases.

That estimate is for Intel hardware with patched microcode.

Thanks Michael for testing the assembler changes with AMD CPUs:

https://www.phoronix.com/scan.php?page=news_item&px=AMD-With-Intel-JCC-Assembler

[fintux]

From what i see it is mostly a couple of bytes per certain branch/jump. For a significant portion your code would have to be full of branches which would run like shit anyway.

Anything that has a condition means that there's branching: if, switch, for, while - they all require branching. Even if it is a simple "if (a) { i += 1; }" has branching, and if all of this needs to be padded, there will be a lot of no-ops. So branches are pretty important in software. I would say it's the biggest difference between a calculator and a computer.

As you can see from the benchmarks in this article, there are many cases where the performance is not restored by these patches, and I don't see any other reason for this than the increased cache misses. This would also explain why the more mathematical benchmarks seem to take less of a hit than application benchmarks - the mathematical ones probably have less branching than applications. Until there are other theories than the increased cache misses for this kind of performance loss with the assembler patches, my working theory stays the same.

[coder]

Knowing assembly and understand internal computer memory structures is a skill necessary only for micro optimizations, but most software does not need that.

I would never dissuade someone from learning assembly language - only using it!

For a few years, I had a job writing hard-realtime firmware for a chip that didn't have a usable C compiler, for the purpose. The main takeaway was proper respect and appreciation for compilers. Not that I hadn't before, but years of that stuff will really drive home the point.

What's most useful about knowing assembly language is being able to look at compiler output, to see if there's something about the code that's tripping it up. On occasion, I've even found cause to whip out some inline assembly, for something really small and specialized, where I just couldn't seem to get the compiler to do what I want. Not recently, though.