Timeline for When did compilers start generating optimized code that runs faster than an average programmer's assembly code?
Current License: CC BY-SA 4.0
47 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 29, 2023 at 11:00 | answer | added | John Dallman | timeline score: 3 | |
| Apr 28, 2023 at 11:10 | answer | added | Simon Farnsworth | timeline score: 6 | |
| Sep 29, 2021 at 3:37 | answer | added | Schezuk | timeline score: 0 | |
| Mar 2, 2021 at 16:38 | answer | added | Maury Markowitz | timeline score: 3 | |
| Mar 2, 2021 at 1:33 | answer | added | KRK Owner | timeline score: 1 | |
| Oct 10, 2020 at 17:20 | history | edited | user3840170 | CC BY-SA 4.0 |
added 7 characters in body; edited title
|
| S Sep 30, 2020 at 20:09 | history | bounty ended | 15628 | ||
| S Sep 30, 2020 at 20:09 | history | notice removed | 15628 | ||
| Sep 27, 2020 at 23:45 | answer | added | KRK Owner | timeline score: 1 | |
| Sep 26, 2020 at 17:25 | history | edited | user3840170 | CC BY-SA 4.0 |
rearrange words to avoid slightly ambiguous bracketing
|
| S Sep 26, 2020 at 15:38 | history | bounty started | 15628 | ||
| S Sep 26, 2020 at 15:38 | history | notice added | 15628 | Reward existing answer | |
| Sep 26, 2020 at 13:06 | vote | accept | Schezuk | ||
| Sep 16, 2020 at 20:37 | comment | added | supercat | @introspec: Agreed, but code using IY-based automatic objects is so much slower than code using statically-allocated ones that moving from the latter to the former would save more execution time than any further improvements one could make beyond that. BTW, I find it sad that LDI-family instructions decrement BC rather than just B. Decrementing just B would have allowed execution to be two cycles faster, and even if code had to follow an LDIR with DEC C/JP NZ, an extra 14 cycles every 256 bytes to manage the high-byte count would have been a lot cheaper than 2 cycles every byte. | |
| Sep 16, 2020 at 20:33 | comment | added | supercat | ...much clunkier than they really should be. Incidentally, I find myself wondering if the design of the Z80's new instructions was done at a time when the chip was expected to have an 8-bit ALU, and if the decision to use a 4-bit ALU was based upon the adequacy of a 4-bit ALU for the instructions inherited from the 8080? A lot of the instruction set decisions would make sense given an 8-bit ALU, but the 4-bit ALU imposes such a severe time penalty as to seriously degrade their usefulness. | |
| Sep 16, 2020 at 20:33 | comment | added | introspec | @supercat, recursion definitely was one of the key issues. However, I think that the issue is much deeper than that. In demomaking for Z80 we have some very successful patterns like POP HL : LDI (which is a LUT translating specially-formed pairs of values into bytes) or its slightly more complex variation POP HL : LDI : LD A,(HL) : LD (BC),A. To write code like this you actively move stack pointer, pre-allocate specific parts of memory to optimize LUT access based on the address ranges that you will need to use, etc, etc. It is really a very different mode of thinking. | |
| Sep 16, 2020 at 20:23 | comment | added | supercat | @introspec: IMHO, the Standard's requirement that C implementations report recursion really sunk the quality of C compilers for that platform. On platforms where recursion would be totally impractical (e.g. 8051 or PIC) linkers can statically allocate local variables so that functions which are never live simultaneously can store their variables in the same place. If one avoids using stack-allocated variables, the Z80 can be almost workable as a C platform (I've used it), though having 8-bit operations require values in A while 16-bit operations require values in HL makes many things... | |
| Sep 16, 2020 at 20:18 | comment | added | introspec | @supercat, My experience with assembly a lot more retro, so I best qualified to talk about Z80. And I think that it is an excellent CPU to consider in this context, because it is fairly different from the higher-level language abstractions people so used to nowadays. E.g., the most efficient paradigm for Z80 filling memory is to set up sequences of PUSH instructions, possibly interdispersed with commands for reloading CPU registers. This is so unlike to the way in which C operates, that any form of machine translation cannot possibly map onto this paradigm well. | |
| Sep 16, 2020 at 17:02 | comment | added | supercat | @introspec: On the Cortex-M0, Loading each word, adding 0x7F7F7F7F [value kept in register], "and-not"ing with 0x7F7F7F7F, shifting right 7, subtracting from the original, and storing it back would take eight cycles per four bytes not counting loop overhead. Consolidating loads and stores to use LDM/STM would take 26 cycles per 16 bytes while leaving a "low" register available as a loop counter. I can't imagine any compiler coming anywhere near close to that. | |
| Sep 16, 2020 at 16:57 | comment | added | supercat | @introspec: Often, getting inner loops right requires knowing things that programmers can't very well convey. For example, suppose one is targeting a typical 32-bit ARM, has a word-aligned group of 256 bytes that will hold values 0..127, wants to decrement all the ones that are non-zero, and would regard it acceptable if the presence of any byte value 128..255 arbitrarily disturbs the values of any other bytes in the region. Is there any portable way to specify such behavior in a way that would allow a compiler to generate code that isn't at least twice as slow as optimal? | |
| Sep 16, 2020 at 16:20 | comment | added | introspec | @supercat, yes, absolutely. No-one is saying that everything needs to be written in assembly, it is usually impractical and unnecessary. However, the performance of even the best compilers at getting these really hot innerloops right is rarely impressive from the point of view of real assembly programmers. | |
| Sep 16, 2020 at 15:31 | comment | added | supercat | @introspec: I once took some DSP code that had been written entirely in assembly language except for some floating-point math (fixed-point DSP!) which the programmer didn't know how to write in assembly language. I reworked some of the math to use some short assembly-languages for multiply-accumulate, simple FIR filtering, and integer square root, and rewrote everything else in C. System went from running about 20% as fast as needed to running 5-10x as fast as needed, but with a tiny fraction as much assembly-language code. | |
| Sep 16, 2020 at 13:40 | comment | added | introspec | @Alan B, it does not really matter what proportion of the routines is in C. What matters is the proportion of time your program sits in that single routine written in assembly. And then the speed-up that can be reached in a well-tuned assembly routine vs output of the optimizing compiler can easily translate into appreciable speed-up of the whole program. | |
| Sep 16, 2020 at 11:33 | history | edited | dave | CC BY-SA 4.0 |
Removed the added restriction to C; I don't see that as the original intent.
|
| Sep 16, 2020 at 6:21 | comment | added | Alan B | I remember Carmack or Romero being interviewed when Wolf 3D came out and them saying that one line drawing routine aside it was all C.At that point in time it was surprising (to me at least) that this was the case. Later discovered that the Amiga version of Marble Madness was in C. | |
| Sep 16, 2020 at 1:15 | history | edited | dave |
edited tags
|
|
| Sep 15, 2020 at 21:35 | answer | added | skamradt | timeline score: 7 | |
| Sep 15, 2020 at 14:27 | comment | added | Andrew Henle | @IanRingrose "CPUs optimized for GCC" happened long after compilers could beat decent hand-coded assembly. In the early 90s, GCC was effectively non-existent on Sun workstations. But even back then, IME Sun's compiler produced optimized code that was about as fast if not faster than decent assembly - but with a lot less programmer effort required. I'd guess compilers were "winning" widely by the late 80s at the latest. | |
| Sep 15, 2020 at 0:36 | answer | added | Bill Ferguson | timeline score: 7 | |
| Sep 14, 2020 at 20:30 | comment | added | Thomas | my personal experience (video games, so it was all asm then later moved to C++) is that hand asm was always faster, but become not worth it around the Pentium 3 era, but for some specialized code. The one thing that took very long for compilers to be good at was generating the FPU code for math operations. | |
| Sep 14, 2020 at 15:40 | comment | added | dave | What's an "average" assembly-language programmer these days, though? Is the average getting better because only the motivated need to do it? | |
| Sep 14, 2020 at 12:23 | answer | added | Patrick Schlüter | timeline score: 7 | |
| Sep 14, 2020 at 10:51 | comment | added | Thorbjørn Ravn Andersen | There is no problem with writing assembly by hand except that you are less productive - you can only write a certain amount of code per day - and you can pack more work into higher level language code than assembly. So by pure economics it doesn't make sense for humans to write assembly. An exception is when you have code that needs to be as fast as absolutely possible where an experienced assembly programmer MAY be able to know things that it is not yet possible to let a programmer hint to a compiler. | |
| Sep 14, 2020 at 10:30 | comment | added | Russell McMahon | Never I tell you!, never, never ....... [ :-) ] | |
| Sep 13, 2020 at 22:41 | answer | added | supercat | timeline score: 13 | |
| Sep 13, 2020 at 22:40 | answer | added | mcleod_ideafix | timeline score: 29 | |
| Sep 13, 2020 at 19:46 | answer | added | Cecil Ward | timeline score: 55 | |
| Sep 13, 2020 at 18:19 | comment | added | Ian Ringrose | On Unix workstations, as most software was compiled with GCC, the CPUs started to be designed to run code compiled by GCC faster. | |
| S Sep 13, 2020 at 17:24 | history | mod moved comments to chat | |||
| S Sep 13, 2020 at 17:24 | comment | added | Chenmunka♦ | Comments are not for extended discussion; this conversation has been moved to chat. | |
| S Sep 13, 2020 at 8:32 | history | suggested | Alex R | CC BY-SA 4.0 |
clarification
|
| Sep 13, 2020 at 5:55 | review | Suggested edits | |||
| S Sep 13, 2020 at 8:32 | |||||
| Sep 13, 2020 at 2:41 | answer | added | Loren Pechtel | timeline score: 12 | |
| Sep 12, 2020 at 21:56 | answer | added | Mark Morgan Lloyd | timeline score: 22 | |
| Sep 12, 2020 at 17:36 | history | became hot network question | |||
| Sep 12, 2020 at 9:43 | answer | added | Chromatix | timeline score: 40 | |
| Sep 12, 2020 at 9:29 | history | asked | Schezuk | CC BY-SA 4.0 |