I'm all for experimenting and digging into what the generated code actually looks like. Just remember that it's a moving target, and that you should not assume that the code choices will look similar in the future.
E.g. I'm working on a presentation that demonstrations of how our JITs make use of the capabilities of newer Intel cores. To study machine code, I generally "make it hot" (e.g. with jmh, using DONT_INLINE directives) and then look at it with ZVision (a feature of Zing), which is very useful because the instruction-level profiling ticks allow me quickly identify and zoom into the actual loop with the code I want to study (and ignore the 90%+ rest of the machine code that is not the actual hot loop). Below is a short sequence from my work-in-progress slide deck. It demonstrates how much of a moving target code-gen is for the exact same code, and even the exact same compiler (e.g. varying according to the core you are running on). In this case you are looking at what Zing's Falcon JIT generates fro Westmere vs. Broadwell for the same simple loop. But the same sort of variance and adaptability will probably be there for other JITs and static compilers. <https://lh3.googleusercontent.com/-eAa-Lluz1Ss/WH3YsAlHKtI/AAAAAAAAAPY/Yn3sJQv50kA5Bjrlp7imxfn2u60WXYIoACLcB/s1600/Java_Intel_Jan2017%2Btmp.001.jpeg> <https://lh3.googleusercontent.com/-qbYzAVA2eIk/WH3YxHl5WTI/AAAAAAAAAPc/CJpm7YZbLpAR-fGBgrs_xD-Oz3XkqqSfwCLcB/s1600/Java_Intel_Jan2017%2Btmp.002.jpeg> <https://lh3.googleusercontent.com/-WlLoyCc3zsg/WH3Y1hoPIKI/AAAAAAAAAPg/jyLk8DNvpv4RJe41XAj18rbIeXZDKFRtgCLcB/s1600/Java_Intel_Jan2017%2Btmp.003.jpeg> <https://lh3.googleusercontent.com/-eTbu9Jt6SHI/WH3Y7FfyckI/AAAAAAAAAPk/cMGUBGYd3x4BiWb_W7VZRUl8ZzOqlUrmgCLcB/s1600/Java_Intel_Jan2017%2Btmp.004.jpeg> Here are two different On Tuesday, January 17, 2017 at 2:41:21 AM UTC-5, Francesco Nigro wrote: > > Thanks, > > "Assume nothing" is a pretty scientific approach,I like it :) > But this (absence of) assumption lead me to think about another couple of > things: what about all the encoders/decoders or any program that rely on > data access patterns to pretend to be and remain "fast"? > Writing mechanichal sympathetic code means being smart enough to trick the > compiler in new and more creative ways or check what a compiler doesn't > handle so well,trying to manage it by yourself? > The last one is a very strong statement just for the sake of > discussion..But I'm curious to know what the guys of this group think about > it :) > > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
