3 ms·

"I still see plenty of unnecessary data shuffling and other things no sane human Asm programmer would ever do." OK, but in the general case, at scale, in a com

"I still see plenty of unnecessary data shuffling and other things no sane human Asm programmer would ever do." OK, but in the general case, at scale, in a complex program, compilers are better able to make register allocation decisions than humans. Some compilers may not be as good as others, and I would love to see some examples, but it has been a long time since this debate was settled. "A compiler can analyse dataflow and somewhat understand, but especially when external functions are involved, the knowledge is still incomplete." https://en.wikipedia.org/wiki/Interprocedural_analysis https://en.wikipedia.org/wiki/Interprocedural_analysis Sure, dynamic linking throws a wrench into things, but equally true for humans who may not understand how the function they are calling really works. "making one part of the code smaller, although somewhat slower, could allow another more critical part to fit completely into cache and improve performance overall." I am sure it happens. It is far more common for that sort of optimization to be irrelevant due to the size and complexity of the system. Compilers are also capable of optimizing for code size, it is similar to optimizing for speed but not important in most cases.

jsjohnst 9y ago
> OK, but in the general case, at scale, in a complex program, compilers are better able to make register allocation decisions than humans. Some compilers may not be as good as others, and I would love to see some examples, but it has been a long time since this debate was settled. You keep repeating that assumption, but offer zero proof or even any argument really to why it might be true even.
- spc476 9y ago
  Back in the late 80s/early 90s, I did a lot of assembly language programming---6809, 68000, 8088 and MIPS, so it's not unfamiliar to me. I haven't really done any assembly language programming since ... eh ... 1995, so okay, I could be a bit rusty. Anyway, a few weeks ago, I picked up one of the projects I worked in the early 90s, a mildly math heavy program that dealt with a pair of functions that I thought could easily be vectorized and oh! The Pentiums of today have vector instructions, and in reading over the programming manual, yes, it looked like it would be straightforward to write some vector code, in assembly (something I haven't done---should be fun). My code easily beat clang (using C code) on its highest optimization setting. Easily beat, but it got pretty close. GCC? It (again, using the C version of the code) was smoking my code at -O2 by an embarrassing amount. And it wasn't even using the vectorized instructions! And to make sure, I ran the code on several different systems, so I don't think it was this version of the Pentium having a bad MMX implementation over that Pentium. I haven't taken the time to figure out what GCC did (perhaps it knows better how to schedule MMX code than I do) as I was doing this for fun, not profit. All the data I was working with was in registers in my code.

jsjohnst 9y ago

> OK, but in the general case, at scale, in a complex program, compilers are better able to make register allocation decisions than humans. Some compilers may not be as good as others, and I would love to see some examples, but it has been a long time since this debate was settled. You keep repeating that assumption, but offer zero proof or even any argument really to why it might be true even.

spc476 9y ago
Back in the late 80s/early 90s, I did a lot of assembly language programming---6809, 68000, 8088 and MIPS, so it's not unfamiliar to me. I haven't really done any assembly language programming since ... eh ... 1995, so okay, I could be a bit rusty. Anyway, a few weeks ago, I picked up one of the projects I worked in the early 90s, a mildly math heavy program that dealt with a pair of functions that I thought could easily be vectorized and oh! The Pentiums of today have vector instructions, and in reading over the programming manual, yes, it looked like it would be straightforward to write some vector code, in assembly (something I haven't done---should be fun). My code easily beat clang (using C code) on its highest optimization setting. Easily beat, but it got pretty close. GCC? It (again, using the C version of the code) was smoking my code at -O2 by an embarrassing amount. And it wasn't even using the vectorized instructions! And to make sure, I ran the code on several different systems, so I don't think it was this version of the Pentium having a bad MMX implementation over that Pentium. I haven't taken the time to figure out what GCC did (perhaps it knows better how to schedule MMX code than I do) as I was doing this for fun, not profit. All the data I was working with was in registers in my code.