One of the interesting aspects of benchmarks is that they are usually designed and intended to run in isolation. E.g. if you benchmark a database system, you expect that to be the sole system running on your server machine, in control of all resources.
That's not true of software running on desktop systems or mobile phones - desktops usually run many concurrent tasks, so do phones to some degree, and then there's also the question of battery use.
That can create skewed incentives if the benchmark isn't carefully designed. E.g. you can usually make space/time tradeoffs regarding performance, so if your benchmark is solely measuring CPU time, it pays off to gobble up all possible RAM for even minor benefits. If your benchmark is only measuring wallclock time, it pays off to gobble up all the CPUs, even if the actual speedup from that is minor.
This can lead to software "winning" the benchmark with improvements that are actually detrimental to the performance on end user's systems.
When I saw the title of this article, I got really excited because I thought they were referring to a lighter "build".
IMHO, one of the biggest problems facing v8 right now is the build process. You need to download something like 30 gigs of artifacts, and building on windows is difficult - to say the least.
It's bad enough that the trusted postgres extension plv8 is considering changing it's name to pljs and switching engines to something like QuickJS. [0]
One of the driving factors is that building and distributing v8 as a shared lib as part of a distro is incredibly difficult, and increasing numbers of distros are dropping it. This has downstream effects for anyone (like plv8) that are linking to it.[1]
Also, embedding it is super complex. Referenced in the above conversation is a discussion that NodeJS had to create their own build process for v8. At this point, it's easier to user the NodeJS build process and use the Node v8 API than it is to use v8 directly.
At the beginning of the article, they are talking about building a "v8 light" for embedded application purposes, which was pretty exciting to me, then they diverged and focused on memory optimization that's useful for all v8. This is great work, no doubt, but as the most popular and well tested JavaScript engine, I'd love to see a focus on ease of building and embedding.
I completely agree that the most difficult part of using V8 is the build process. In node we have three layers (!!!) of build tooling stacked together to insulate ourselves from it (gyp, ninja, and some extra python scripts), and it still requires constant effort to keep working. Deno just gave up and uses GN, but that requires some stupidly complex source layouts and yet more python scripts. Unfortunately, Google just doesn't care about making V8 work with external tooling, it's all about their chromium build process. And this is a real shame, because V8 has the best embedding API of any js engine I know of, it really is a joy to use.
> At the beginning of the article, they are talking about building a "v8 light" for embedded application purposes, which was pretty exciting to me, then they diverged and focused on memory optimization that's useful for all v8. This is great work, no doubt, but as the most popular and well tested JavaScript engine, I'd love to see a focus on ease of building and embedding.
Would you ever consider an engine designed for that, like XS?[1] Or is it V8-or-nothing as far as you're concerned?
I think Firefox went through something similar many many years ago, a Project called MemShrink started after many user were complaining how Firefox were getting slower and bloated with Firefox 3 - 4* if I remember correctly.
It was Memory optimisation in every part of Firefox and mostly in SpiderMonkey.
That's literally how Flutter started. "What if we don't have to be backwards compatible? Let's delete the HTML parsing quirks... and expensive CSS selectors... and... all of the DOM... and JavaScript... and why do we have markup even..."
Roughly anything before HTML5/4.01 and XHTML renders in quirks mode.
AFAIK there are no legacy CSS properties. Only nonstandard (i.e. prefixed or experimental and never published in finished specs) properties have been deprecated.
It is rather interesting to me to see that V8 has been packing so many micro-optimizations and special techniques over the years that now it has become actually feasible to just start cutting back on the optimizations to have performance gains.
What all this enables is, beside having more sensible defaults, is the ability for developers who use V8 with Electron or NW.js to tweak the default behavior of the engine, catering to their application's needs. That is always good.
That's not what I took away from this at all. They specifically say that Lite mode started out as a way to reduce memory consumption at the cost of performance. Execution time jumped 120%!
Then they figured out how to get the memory improvements without the performance hit. The only place where they actually removed optimizations was in generating stack traces, and that wasn't a gain in performance, it was just considered acceptable for that to get slower.
I did some work on a Python JIT in the path. The two biggest challenges were:
- Python is much, much, more dynamic than Javascript. You can override just about anything in Python, including the meaning of accessing a property. You have overloaded operators (with pretty complex resolution rules), metaclasses, and more. And they're all used extensively. There's some Javascript equivalents to those things, but either there are fewer deoptimization cases or are features that aren't commonly used in practice (e.g. Proxy objects).
- Python has a ton of important libraries implemented as C extensions. These libraries tend to depend on undefined behavior of the CPython interpreter (e.g. destruction order which is more deterministic with ref counting) or do things that happen to work but are clearly not supposed to be done (e.g. defining a full Python object as a static variable).
I guess also economic incentives, there hasn't been an incentive for anybody to staff a 50 person project to build a Python JIT given that it's cheaper to rewrite some or all of the application in C/C++/Rust/Go whereas that's not an option in Javascriptland.
Besides the existence of __getattr__, __add__, etc. that other people mentioned, there's also:
- A Python runtime has to support threads + shared memory, while a JS one doesn't. JS programs are single-threaded (w/ workers). So in this sense writing a fast Python interpreter is harder.
- The Python/C API heavily constrains what a Python interpreter can do. There several orders of magnitude more programs that use it than v8's C++ API.
For example, reference counts are exposed with Py_INCREF/DECREF. That means it's much harder to use a different reclamation scheme like tracing garbage collection. There are thousands of methods in the API that expose all sorts of implementation details about CPython.
Of course PyPy doesn't support all of the API, but that's a major reason why it isn't as widely adopted as CPython.
- Python has multiple inheritance; JS doesn't
- In Python you can inherit from builtin types like list and dict (as of Python 2.2). In JS you can't.
- Python's dynamic type system is richer. typeof(x) in JS gives you a string. type(x) in Python gives you a type object which you can do more with. And common programs/frameworks make use of this introspection.
- Python has generators, Python 2 coroutines (send, yield from), and Python 3 coroutines (async/await).
In summary, it's a significantly bigger language with a bigger API surface area, and that makes it hard to implement and hard to optimize. As I learn more about CPython internals, I realize what an amazing project PyPy is. They are really fighting an uphill battle.
V8 has the full resources of Google, not to mention Microsoft, Node.js, and every community that uses the V8 engine.
Basically V8 has some of the best engineers in the world being paid to work full time on it, and have resources from dozens of other high profile companies.
Not knocking python in any way - V8 essentially just has more resources available. I highly recommend trying pypy if you're looking for a performance benefit and your code works with it.
Many of the techniques used in modern JS VMs like v8 or JavaScriptCore could totally be applied to a Python interpreter, and it wouldn't take 50 people. Someone just needs to invest the effort. The core techniques are a fast-start interpreter, a templatized baseline JIT, polymorphic inline caches, and runtime type information combined with higher JIT tiers that speculatively optimize for observed types, which allows many checks throughout the generated code to be replaced by side exits. (Also a good garbage collector, and escape analysis to avoid allocating temporaries).
I believe most of these could be applicable to Python. JavaScript has crazy levels of dynamism too, and the above methods are the short version of how you deal with it.
It seems like no one in the Python community has had the knowledge + motivation to try these approaches.
There's a bunch of things: Python allows metaprogramming in a way that JS does, which means you end up needing more guards (or conflating more guards); the Python ecosystem fairly heavily relies on CPython extension modules, and if you wish to remain compatible with them you're constrained in some ways, especially if you care about performance of calling into/from them.
Have you tried pypy? I got about 2x of C performance for a simulated annealing problem I was working on recently. Ultimately what I realized was that the clever python structures that made prototyping fast were inherently slow (dicts with tuple keys, etc). Once I ported it to C, then went back to python and used the same simple data structures, pypy was practically just as fast as C.
History suggests that, for a good approximation of the truth, the resources put into a language implementation (and, in particular, into JIT compiling VMs) strongly correlate with its performance. So V8 and HotSpot, for example, both have great performance -- and both have had large teams working on them for many years.
Interestingly, PyPy has pretty decent performance despite having had a much smaller team working on it, mostly part-time. An interesting thought experiment is whether similar resources put into PyPy -- or a PyPy-like system -- would achieve similar results. My best guess is "yes".
I can't speak to JSC, but at least SpiderMonkey has had memory optimizations that are equivalent to the ones described here (e.g. discarding cold-function bytecode) for a while... I agree that it would be interesting to have more competition, including more measurement, in this space.
Somewhat off-topic, but is there an RSS feed available for the V8 blog? Their posts are always interesting to me, but I've searched a few times with no luck.
I wonder if something like this could be used to build an electron alternative (or modify the existing electron backend to use this engine), since memory usage is a major complaint for these applications
> If you prefer watching a presentation over reading articles, then enjoy the video below! If not, skip the video and read on.
This is OT, but I think we can design a format with the best of both worlds. We can have the personal and narrated quality of videos/voiceovers, along with the skimmable/scannable/interactive quality of web content.
I agree, having a transcript of a video is very useful. I've done that with some of my own and other people's videos.
It takes a lot less time to skim over an illustrated transcript than to watch a video, and it lets the readers decide if they're interested enough in actually taking the time to watch the video. Plus it's search engine friendly, and lets you add more links and additional material.
I loved the body language in this classic Steve Jobs video so much that I was compelled to write a transcript with screen snapshots focusing on and transcribing all of his gestures (in parens). After reading the transcript, it's still interesting to watch the video, after you know what body language to look for!
“Focusing is about saying no.” -Steve Jobs, WWDC ‘97
As sad as it was, Steve Jobs was right to “put a bullet in OpenDoc’s head”. Jobs explained (and performed) his side of the story in this fascinating and classic WWDC’97 video: “Focusing is about saying no.”
If only HTML could have hyperlinks, embedded multimedia and textual content in a single file...
(In all seriousness, it's sad that YouTube has such a narrow focus — video files only — which helped it spread to many different devices, from small phones to TVs, but hinders interactivity)
This is a little off-topic, but I find the terminology used in software these days to be a little perplexing. Is "small", a perfectly adequate word to describe less memory usage, not buzzwordy/trendy enough?
"light" or "heavy" just reminds me of that classic story about the weight of software.
Why not allow the runtime to call the garbage collector (GC)? The GC is very lazy by default, it should be possible to make it collect all garbage. Currently v8 will just let the garbage grow because the GC is so lazy.
Probably should be re-titled to match the post as people are getting confused by the reference to V8 lite, which this post isn't directly about.
> However, in the process of this work, we realized that many of the memory optimizations we had made for this Lite mode could be brought over to regular V8 thereby benefiting all users of V8.
> ...we could achieve most of the memory savings of Lite mode with none of the performance impact by making V8 lazier.
Yes, the submitted title ("V8 lite (22% memory savings)") broke the site guideline which asks: "Please use the original title, unless it is misleading or linkbait; don't editorialize."
Doing this tends to skew discussions enormously, so please follow the guidelines!
This is great, but because you have achieved memory reduction by trading off speed, it would be nice to see charts that show processing time increases too.
[+] [-] Nitramp|6 years ago|reply
That's not true of software running on desktop systems or mobile phones - desktops usually run many concurrent tasks, so do phones to some degree, and then there's also the question of battery use.
That can create skewed incentives if the benchmark isn't carefully designed. E.g. you can usually make space/time tradeoffs regarding performance, so if your benchmark is solely measuring CPU time, it pays off to gobble up all possible RAM for even minor benefits. If your benchmark is only measuring wallclock time, it pays off to gobble up all the CPUs, even if the actual speedup from that is minor.
This can lead to software "winning" the benchmark with improvements that are actually detrimental to the performance on end user's systems.
[+] [-] claytongulick|6 years ago|reply
IMHO, one of the biggest problems facing v8 right now is the build process. You need to download something like 30 gigs of artifacts, and building on windows is difficult - to say the least.
It's bad enough that the trusted postgres extension plv8 is considering changing it's name to pljs and switching engines to something like QuickJS. [0]
One of the driving factors is that building and distributing v8 as a shared lib as part of a distro is incredibly difficult, and increasing numbers of distros are dropping it. This has downstream effects for anyone (like plv8) that are linking to it.[1]
Also, embedding it is super complex. Referenced in the above conversation is a discussion that NodeJS had to create their own build process for v8. At this point, it's easier to user the NodeJS build process and use the Node v8 API than it is to use v8 directly.
At the beginning of the article, they are talking about building a "v8 light" for embedded application purposes, which was pretty exciting to me, then they diverged and focused on memory optimization that's useful for all v8. This is great work, no doubt, but as the most popular and well tested JavaScript engine, I'd love to see a focus on ease of building and embedding.
0: https://github.com/plv8/plv8/issues/364
1: https://github.com/plv8/plv8/issues/308#issuecomment-4347400...
[+] [-] snek|6 years ago|reply
[+] [-] vvanders|6 years ago|reply
[+] [-] CharlesW|6 years ago|reply
Would you ever consider an engine designed for that, like XS?[1] Or is it V8-or-nothing as far as you're concerned?
[1] https://news.ycombinator.com/item?id=16883567
[+] [-] microcolonel|6 years ago|reply
[+] [-] syspec|6 years ago|reply
* The browser becomes completely unresponsive, each time you hit a breakpoint for 3-5 seconds.
* It also takes chrome much longer to show you the source maps for a page
* If you refresh while on a breakpoint it will remain unresponsive for nearly 10 seconds.
Is this related to these new changes? Is there a way to revert the trade off?
[+] [-] JMTQp8lwXL|6 years ago|reply
Glad to hear I'm not alone in experiencing this. For a period, I thought I had written bad code that caused Chrome to stumble. Guess it's just Chrome.
[+] [-] lacampbell|6 years ago|reply
[+] [-] jlu|6 years ago|reply
In the mean time, one work around is not to hit refresh, instead hit F8 and let it exit the breakpoint normally.
[+] [-] ksec|6 years ago|reply
It was Memory optimisation in every part of Firefox and mostly in SpiderMonkey.
[+] [-] truth_seeker|6 years ago|reply
I hope V8 v7.8 makes it to Node v12 before its LTS release in coming October.
[+] [-] pier25|6 years ago|reply
Is there any engine/browser mode/something that lets go of legacy JS/CSS/HTML and increases performance/weight/memory consumption?
A browser/JS engine with removed legacy support would in principle be much faster, no?
[+] [-] Hixie|6 years ago|reply
[+] [-] untog|6 years ago|reply
https://sciter.com/
It allows you to make desktop apps with HTML/CSS, but it has its own custom engine that doesn't support all the quirks the web does.
[+] [-] jitl|6 years ago|reply
What is “legacy” CSS? Box model?
What is “legacy” HTML? <br>?
[+] [-] dictum|6 years ago|reply
Roughly anything before HTML5/4.01 and XHTML renders in quirks mode.
AFAIK there are no legacy CSS properties. Only nonstandard (i.e. prefixed or experimental and never published in finished specs) properties have been deprecated.
Browsers already have some leeway with DOM APIs. https://developers.google.com/web/updates/2017/01/scrolling-...
[+] [-] the8472|6 years ago|reply
[+] [-] jannes|6 years ago|reply
[+] [-] angrygoat|6 years ago|reply
[+] [-] Sawamara|6 years ago|reply
What all this enables is, beside having more sensible defaults, is the ability for developers who use V8 with Electron or NW.js to tweak the default behavior of the engine, catering to their application's needs. That is always good.
[+] [-] cwp|6 years ago|reply
Then they figured out how to get the memory improvements without the performance hit. The only place where they actually removed optimizations was in generating stack traces, and that wasn't a gain in performance, it was just considered acceptable for that to get slower.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] andrewhodel|6 years ago|reply
They should have ACID sub-tests for images, videos, etc so these statistics would actually provide something long term and important.
[+] [-] umvi|6 years ago|reply
[+] [-] rudi-c|6 years ago|reply
- Python is much, much, more dynamic than Javascript. You can override just about anything in Python, including the meaning of accessing a property. You have overloaded operators (with pretty complex resolution rules), metaclasses, and more. And they're all used extensively. There's some Javascript equivalents to those things, but either there are fewer deoptimization cases or are features that aren't commonly used in practice (e.g. Proxy objects).
- Python has a ton of important libraries implemented as C extensions. These libraries tend to depend on undefined behavior of the CPython interpreter (e.g. destruction order which is more deterministic with ref counting) or do things that happen to work but are clearly not supposed to be done (e.g. defining a full Python object as a static variable).
I guess also economic incentives, there hasn't been an incentive for anybody to staff a 50 person project to build a Python JIT given that it's cheaper to rewrite some or all of the application in C/C++/Rust/Go whereas that's not an option in Javascriptland.
[+] [-] chubot|6 years ago|reply
- A Python runtime has to support threads + shared memory, while a JS one doesn't. JS programs are single-threaded (w/ workers). So in this sense writing a fast Python interpreter is harder.
- The Python/C API heavily constrains what a Python interpreter can do. There several orders of magnitude more programs that use it than v8's C++ API. For example, reference counts are exposed with Py_INCREF/DECREF. That means it's much harder to use a different reclamation scheme like tracing garbage collection. There are thousands of methods in the API that expose all sorts of implementation details about CPython.
Of course PyPy doesn't support all of the API, but that's a major reason why it isn't as widely adopted as CPython.
- Python has multiple inheritance; JS doesn't
- In Python you can inherit from builtin types like list and dict (as of Python 2.2). In JS you can't.
- Python's dynamic type system is richer. typeof(x) in JS gives you a string. type(x) in Python gives you a type object which you can do more with. And common programs/frameworks make use of this introspection.
- Python has generators, Python 2 coroutines (send, yield from), and Python 3 coroutines (async/await).
In summary, it's a significantly bigger language with a bigger API surface area, and that makes it hard to implement and hard to optimize. As I learn more about CPython internals, I realize what an amazing project PyPy is. They are really fighting an uphill battle.
[+] [-] penagwin|6 years ago|reply
Basically V8 has some of the best engineers in the world being paid to work full time on it, and have resources from dozens of other high profile companies.
Not knocking python in any way - V8 essentially just has more resources available. I highly recommend trying pypy if you're looking for a performance benefit and your code works with it.
[+] [-] om2|6 years ago|reply
I believe most of these could be applicable to Python. JavaScript has crazy levels of dynamism too, and the above methods are the short version of how you deal with it.
It seems like no one in the Python community has had the knowledge + motivation to try these approaches.
[+] [-] gsnedders|6 years ago|reply
[+] [-] fniephaus|6 years ago|reply
[+] [-] deckar01|6 years ago|reply
[+] [-] ltratt|6 years ago|reply
Interestingly, PyPy has pretty decent performance despite having had a much smaller team working on it, mostly part-time. An interesting thought experiment is whether similar resources put into PyPy -- or a PyPy-like system -- would achieve similar results. My best guess is "yes".
[+] [-] pizlonator|6 years ago|reply
I don’t know how V8 and JSC compare on memory but I’m happy for this to become a battleground. Nothing but goodness for users if that happens.
(Worth noting that JSC has had a “mini mode” for a while, but it’s focused on API clients. And I don’t know if it’s as aggressive as what V8 did.)
[+] [-] bzbarsky|6 years ago|reply
[+] [-] nammi|6 years ago|reply
[+] [-] toupeira|6 years ago|reply
(found through the <link> tag on the blog)
[+] [-] non-entity|6 years ago|reply
[+] [-] AriaMinaei|6 years ago|reply
This is OT, but I think we can design a format with the best of both worlds. We can have the personal and narrated quality of videos/voiceovers, along with the skimmable/scannable/interactive quality of web content.
[+] [-] DonHopkins|6 years ago|reply
It takes a lot less time to skim over an illustrated transcript than to watch a video, and it lets the readers decide if they're interested enough in actually taking the time to watch the video. Plus it's search engine friendly, and lets you add more links and additional material.
I loved the body language in this classic Steve Jobs video so much that I was compelled to write a transcript with screen snapshots focusing on and transcribing all of his gestures (in parens). After reading the transcript, it's still interesting to watch the video, after you know what body language to look for!
“Focusing is about saying no.” -Steve Jobs, WWDC ‘97 As sad as it was, Steve Jobs was right to “put a bullet in OpenDoc’s head”. Jobs explained (and performed) his side of the story in this fascinating and classic WWDC’97 video: “Focusing is about saying no.”
https://medium.com/@donhopkins/focusing-is-about-saying-no-s...
[+] [-] dictum|6 years ago|reply
(In all seriousness, it's sad that YouTube has such a narrow focus — video files only — which helped it spread to many different devices, from small phones to TVs, but hinders interactivity)
[+] [-] dkarl|6 years ago|reply
[+] [-] sixplusone|6 years ago|reply
[+] [-] userbinator|6 years ago|reply
"light" or "heavy" just reminds me of that classic story about the weight of software.
[+] [-] z3t4|6 years ago|reply
[+] [-] magicalist|6 years ago|reply
> However, in the process of this work, we realized that many of the memory optimizations we had made for this Lite mode could be brought over to regular V8 thereby benefiting all users of V8.
> ...we could achieve most of the memory savings of Lite mode with none of the performance impact by making V8 lazier.
[+] [-] dang|6 years ago|reply
Doing this tends to skew discussions enormously, so please follow the guidelines!
[+] [-] Andrzejko29|6 years ago|reply
[deleted]
[+] [-] perl4ever|6 years ago|reply
https://grassrootsmotorsports.com/forum/grm/lightweight-v8-e...
[+] [-] abc_lisper|6 years ago|reply