Hacker News Reader

Comment by hamstergene | Hacker News Reader

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.

View on HN

> 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.

> 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.

The bitcode Apple used for their platforms was at a much, much lower level than bytecode used on Android.

Yeah, it was also a custom version, somehow people keep thinking they used LLVM bitcode straight out of the box.

I don't know what Android does… some kind of Java but not Java, right?

In that case it's much less expressive, so developers simply can't do the unsafe/specialized code in the first place. Which means they can't write in C or assembly.

Bitcode was a specific Apple feature that used LLVM's compiler IL and might have promised extra portability, but it didn't really work out and was removed this year. ("LLVM" stands for "low level virtual machine" which is funny because it isn't low level and isn't a virtual machine.)

LLVM is lower level than Python or Java bytecode. LLVM is also virtual machine in the sense of an abstract machine, similar in idea to a process virtual machine. Most usages of "virtual machine" today are talking about system virtual machines, but it's important to note that "virtual machine" is an overloaded phrase.

There is no C or Assembly in IBM and Unisys mainframes and microcomputers.

> 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).

"Bitcode" is the name of a specific Xcode feature in this case, not a general comment.

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.

> 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.

Interesting, I didn't know about -Oz (only -Os for size). -Oz is reportedly mac-specific https://stackoverflow.com/questions/1778538/how-many-gcc-opt...

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.

> 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.

Reply on news.ycombinator.com