Hacker News
points by jeffbee 2 days ago | 0 comments
Language choice has next to nothing to do with browser performance. Servo's "performance-focused" design currently suffers from a 10x gap between it and Chrome on the same platform.
[–] nicoburns 2 days ago
For Style and Layout, Servo is now competitive (and in many cases faster) than Chrome / Firefox according to my benchmarks https://nicoburns.github.io/browser-layout-bench/
[–] fabrice_d 2 days ago
10x gap on which benchmark?
[–] jeffbee 2 days ago
Speedometer 3.1
[–] fabrice_d 2 days ago
Your numbers seem very outdated. Testing on a MacBook Air M4, here's what I get:

- Servo b88af263d11e12288ff3eca0848aaa675d6a52f0: 21.4

- Chrome 157: 60.9

- Safari 27.2: 59.2

- Firefox 159: 41.0

So between 2x and 3x slower than the current "big 3".

[–] jeffbee 1 day ago
OK. The fact that these figures are rapidly changing only underlines my point: language platform has virtually nothing to do with browser performance.
[–] orangeboats 2 days ago
If you are determined enough you can even write V8 in assembly. But how many man-hours would that take?
[–] MobiusHorizons 2 days ago
I think the benchmark is for layout performance not JavaScript execution, but v8 is fast because it emits assembly more so than because of the language it is implemented in. That said, I would be very surprised if there is not hand tuned assembly routines for performance critical routines.
[–] orangeboats 2 days ago
My point was that while you can implement any performant program (be it V8 or Spidermonkey, Blink or Servo) in any language, the effort required to reach a certain performance level differs between the languages.

>v8 is fast because it emits assembly

It emits machine code afaik. And secondly, do you _really_ want to implement the intermediate layers of a JIT in assembly?

[–] MobiusHorizons 1 day ago
I take your point that code organization in assembly is hard, and not worth the performance gains over higher level languages. It’s true, we don’t write much complex software completely in assembly.

However the point I was trying to make is still relevant I think, which is that machine instruction abstraction layer (whether it is serialized as binary machine code or as assembly text) remains a critical piece of what makes high performance software fast even today.

There is a recurring myth I see on HN that suggests abstraction layers are progressive, as though humanity had evolved past the assembly/machine instructions abstraction layer to C to higher level languages leaving lower abstraction layers behind completely. That is simply untrue, and a project like V8 is actually a great example of this, since it not only will have hand tuned assembly routines, but also needs to ship a bespoke compiler which will emit machine instructions.

So even though it’s true we don’t organize our software with assembly language, it remains a key to performance. It could be a custom JIT compiler, hand tuned SIMD code (eg to handle string parsing), or even just checking what the compiler emitted (eg in compiler explorer). Machine instructions remain key to high performance.

[–] orangeboats 1 day ago
You don't seem to know where the machine code are generated from. A big part of a compiler is optimizing intermediate representations of the source code.

I am not going to waste my time with you.