4 ms·

A) I have no idea what to do with the information, but it's fascinating nonetheless. B) Obviously the instruction mix depends on the programs analyzed. The on

by IvyMike 11y ago

A) I have no idea what to do with the information, but it's fascinating nonetheless. B) Obviously the instruction mix depends on the programs analyzed. The ones he analyzed are actually all heavily tuned but smaller programs. I wonder if that changes in other domains. If he ever re-does his analysis, it would be interesting to see something gigantic like OpenOffice, which I'm guessing might even be more MOV based. And maybe something like Octave, which might make use of some more esoteric math functions. C) When he says "three popular open-source applications were disassembled and analysed with a Basic script", I thought he might mean "simple", but downloading the source, he does indeed mean BASIC the programming language. :)

bane 11y ago
I think it's interesting how much time is spent moving things around or preserving state vs computation. Lots of cycles dedicated to that means less is getting done than we might think. This can be useful when building up expected performance models of a system.
- deleted 11y ago
  [deleted]
- rdc12 11y ago
  Hardware designers are aware of this thou, if you take say register-register movs, this can be achieved without actually copying the data, via register renaming. X86_64 ABI switched to being able to pass arguments in registers as well. And the top of the stack will almost certainly be in cache anyway for the old style.
  - pmalynin 11y ago
    Plus, most instructions are actually out-of-order on x86 (hence the out-of-order superscalar). So your "mov" will usually take (effectively) zero cycles -- unless there is a dependency. But compilers are usually smart enough to pipeline the generated code, so the problem is really not a problem at all!
  - TheLoneWolfling 11y ago
    Don't forget that reg->reg movs still take up instruction bandwidth and require decoding. They are nowhere near as expensive as a naive analysis would suggest - but they are nowhere near a free lunch either.
ScottBurson 11y ago
A decade or so ago I would have had a use for this information. I was working on the problem of distinguishing code from data in Windows executables -- which is not always easy because of the presence of computed jumps and multibyte instructions (even if you have a pretty good idea that you're looking at code, you need to figure out exactly which byte it starts on). I wrote a Bayesian analyzer that estimated the likelihood that a given byte was the beginning of an instruction, based on estimated instruction frequencies. It worked very well despite the fact that my frequency estimates were SWAGs [0]. I'm sure it would have worked even better with actual statistics. [0] https://en.wikipedia.org/wiki/Scientific_Wild-Ass_Guess https://en.wikipedia.org/wiki/Scientific_Wild-Ass_Guess

by IvyMike 11y ago

bane 11y ago

I think it's interesting how much time is spent moving things around or preserving state vs computation. Lots of cycles dedicated to that means less is getting done than we might think. This can be useful when building up expected performance models of a system.

deleted 11y ago
[deleted]
rdc12 11y ago
Hardware designers are aware of this thou, if you take say register-register movs, this can be achieved without actually copying the data, via register renaming. X86_64 ABI switched to being able to pass arguments in registers as well. And the top of the stack will almost certainly be in cache anyway for the old style.
- pmalynin 11y ago
  Plus, most instructions are actually out-of-order on x86 (hence the out-of-order superscalar). So your "mov" will usually take (effectively) zero cycles -- unless there is a dependency. But compilers are usually smart enough to pipeline the generated code, so the problem is really not a problem at all!
- TheLoneWolfling 11y ago
  Don't forget that reg->reg movs still take up instruction bandwidth and require decoding. They are nowhere near as expensive as a naive analysis would suggest - but they are nowhere near a free lunch either.

ScottBurson 11y ago

A decade or so ago I would have had a use for this information. I was working on the problem of distinguishing code from data in Windows executables -- which is not always easy because of the presence of computed jumps and multibyte instructions (even if you have a pretty good idea that you're looking at code, you need to figure out exactly which byte it starts on). I wrote a Bayesian analyzer that estimated the likelihood that a given byte was the beginning of an instruction, based on estimated instruction frequencies. It worked very well despite the fact that my frequency estimates were SWAGs [0]. I'm sure it would have worked even better with actual statistics. [0] https://en.wikipedia.org/wiki/Scientific_Wild-Ass_Guess https://en.wikipedia.org/wiki/Scientific_Wild-Ass_Guess