4 ms·

Could it be simply because many binaries were produced by much older, outdated optimizers. Or optimized for size. Also, optimizers usually target “most common

Could it be simply because many binaries were produced by much older, outdated optimizers. Or optimized for size. Also, optimizers usually target “most common denominator” so native binaries rarely use full power of current instruction set. Jumping from that peculiar finding to praising runtime JIT feels like a longshot. To me it’s more of an argument towards distributing software in intermediate form (like Apple Bitcode) and compiling on install, tailoring for the current processor.

kllrnohj 4y ago
> To me it’s more of an argument towards distributing software in intermediate form (like Apple Bitcode) and compiling on install, tailoring for the current processor. Or distribute it in source form and make compilation part of the install process. Aka, the Gentoo model.
jasonwatkinspdx 4y ago
All reasonable points, but examples where JIT has an advantage are well supported in research literature. The typical workload that shows this is something with a very large space of conditionals, but where at runtime there's a lot of locality, eg matching and classification engines.
astrange 4y ago
> To me it’s more of an argument towards distributing software in intermediate form (like Apple Bitcode) and compiling on install, tailoring for the current processor. This turns out to be quite difficult, especially if you're using bitcode as a compiler IL. You have to know what the right "intermediate" level is; if assumptions change too much under you then it's still too specific. And it means you can't use things like inline assembly. That's why bitcode is dead now. By the way, I don't know why this thread is about how JITs can optimize programs when this article is about how Rosetta is not a JIT and intentionally chose a design that can't optimize programs.
- josephg 4y ago
  > That's why bitcode is dead now. WebAssembly seems alive and well. I'm not sure how similar it is to java bitcode but its the same core idea. That said, WASM through v8 is ~3x slower than the same code compiled natively. (Some of this might be due to the lack of SIMD in wasm).
  - astrange 4y ago
    "Bitcode" is the name of a specific Xcode feature in this case, not a general comment.
- pjmlp 4y ago
  Bitcode is dead because Apple got fed up to keep maintaining their own fork with guarantees that regular LLVM doesn't offer. Since 1961 plenty of systems have used bytecodes as executable formats, the most sucessfull still in use, IBM and Unisys mainframes and microcomputers.
- lmm 4y ago
  > This turns out to be quite difficult, especially if you're using bitcode as a compiler IL. You have to know what the right "intermediate" level is; if assumptions change too much under you then it's still too specific. And it means you can't use things like inline assembly. > That's why bitcode is dead now. Isn't this what Android does today? Applications are distributed in bytecode form and then optimized for the specific processor at install time.
  - monocularvision 4y ago
    The bitcode Apple used for their platforms was at a much, much lower level than bytecode used on Android.
    - pjmlp 4y ago
      Yeah, it was also a custom version, somehow people keep thinking they used LLVM bitcode straight out of the box.
AceJohnny2 4y ago
> Or optimized for size. Note that on gcc (I think) and clang (I'm sure), -Oz is a strict superset of -O2 (the "fast+safe" optimizations, compared to -O3 that can be a bit too aggressive, given C's minefield of Undefined Behavior that compilers can exploit). I'd guess that, with cache fit considerations, -Oz can even be faster than -O2.
- MayeulC 4y ago
  Interesting, I didn't know about -Oz (only -Os for size). -Oz is reportedly mac-specific https://stackoverflow.com/questions/1778538/how-many-gcc-optimization-levels-are-there#comment2806054_1778700 https://stackoverflow.com/questions/1778538/how-many-gcc-opt...

kllrnohj 4y ago

> To me it’s more of an argument towards distributing software in intermediate form (like Apple Bitcode) and compiling on install, tailoring for the current processor. Or distribute it in source form and make compilation part of the install process. Aka, the Gentoo model.

jasonwatkinspdx 4y ago

All reasonable points, but examples where JIT has an advantage are well supported in research literature. The typical workload that shows this is something with a very large space of conditionals, but where at runtime there's a lot of locality, eg matching and classification engines.

astrange 4y ago

> To me it’s more of an argument towards distributing software in intermediate form (like Apple Bitcode) and compiling on install, tailoring for the current processor. This turns out to be quite difficult, especially if you're using bitcode as a compiler IL. You have to know what the right "intermediate" level is; if assumptions change too much under you then it's still too specific. And it means you can't use things like inline assembly. That's why bitcode is dead now. By the way, I don't know why this thread is about how JITs can optimize programs when this article is about how Rosetta is not a JIT and intentionally chose a design that can't optimize programs.

josephg 4y ago
> That's why bitcode is dead now. WebAssembly seems alive and well. I'm not sure how similar it is to java bitcode but its the same core idea. That said, WASM through v8 is ~3x slower than the same code compiled natively. (Some of this might be due to the lack of SIMD in wasm).
- astrange 4y ago
  "Bitcode" is the name of a specific Xcode feature in this case, not a general comment.
pjmlp 4y ago
Bitcode is dead because Apple got fed up to keep maintaining their own fork with guarantees that regular LLVM doesn't offer. Since 1961 plenty of systems have used bytecodes as executable formats, the most sucessfull still in use, IBM and Unisys mainframes and microcomputers.
lmm 4y ago
> This turns out to be quite difficult, especially if you're using bitcode as a compiler IL. You have to know what the right "intermediate" level is; if assumptions change too much under you then it's still too specific. And it means you can't use things like inline assembly. > That's why bitcode is dead now. Isn't this what Android does today? Applications are distributed in bytecode form and then optimized for the specific processor at install time.
- monocularvision 4y ago
  The bitcode Apple used for their platforms was at a much, much lower level than bytecode used on Android.
  - pjmlp 4y ago
    Yeah, it was also a custom version, somehow people keep thinking they used LLVM bitcode straight out of the box.

AceJohnny2 4y ago

> Or optimized for size. Note that on gcc (I think) and clang (I'm sure), -Oz is a strict superset of -O2 (the "fast+safe" optimizations, compared to -O3 that can be a bit too aggressive, given C's minefield of Undefined Behavior that compilers can exploit). I'd guess that, with cache fit considerations, -Oz can even be faster than -O2.

MayeulC 4y ago
Interesting, I didn't know about -Oz (only -Os for size). -Oz is reportedly mac-specific https://stackoverflow.com/questions/1778538/how-many-gcc-optimization-levels-are-there#comment2806054_1778700 https://stackoverflow.com/questions/1778538/how-many-gcc-opt...