Re:What Challenges and Trade-Offs Do Optimising Compilers Face?
by tomsmeding on Thursday June 22, 2017 @05:43PM
(#14615581)
> Take the linux kernel, what part is the 10% that needs optimization first?
Well syscall entry/exit would be a contender, but those are already in hand-written assembly anyway, so that doesn't count.
Then I'd go for the read()/write() syscalls; I bet (not verified) that they're called really often in comparison to the other ones, with all the file/socket/IPC I/O that's going on.
I'm in the same camp about language choice though; there's lots of place for slower and easier languages, like Python in the role of gluing together high-performance C code, but there are still also lots of scenarios where an across-the-board performant language seems a good fit. Compilers spring to mind, but they are even an extreme example.
Re:What Challenges and Trade-Offs Do Optimising Compilers Face?
by Retra on Thursday June 22, 2017 @10:27PM
(#14616764)
Aren't read()/write() going to be waiting on memory most of the time? Wouldn't you rather have faster context switching first?
Re:What Challenges and Trade-Offs Do Optimising Compilers Face?
by tomsmeding on Friday June 23, 2017 @02:44AM
(#14617404)
Very true, didn't think of that one.
These days, with CPU vendors putting in massive effort for <10% performance improvements, getting a 2x speedups in applications that compile to hundreds of MB's, is more "free" performance than you are likely to gain over the next decade from the hardware vendors.
Lastly, the kinds of code paths most suited to these gains are also the hardest to benchmark. Which is why I fall into the camp that believes picking a fairly performant language is more valuable than a small bump in developer productivity for a little syntactic sugar for anything more complex than throw away code.