An overview of V8 | Hacker News Reader

An overview of V8

blog.appsignal.com

81 pointsLiriel29 comments

This talk between Lars Bak (creator of V8) and Eric Meijer from 2009 is really good. It covers the same material as the article, with a little be more depth.

https://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-...

Lately, more often then not, when I do a test of javascript perf v8 is at the bottom of performance compared to Spidermonkey and Nitro (or whatever the name of Safari's engine is). And I'm not talking a few percent. I'm talking 2x to 20x.

Not every test, but enough that at least on micro benchmarks v8 seems to be the at the bottom at the moment which is disappointing.

It's possible on more common use cases they are closer on perf.

> However, V8 creates an environment of a single thread for each of JavaScript’s execution context. The rest is kept under its control.

Maybe it's because I'm not a native speaker, but to me this sounds like they're saying the V8 creates one thread per execution context. I've been working with V8 for months now and this doesn't make any sense to me.

Can someone clarify whether I simply misunderstood the phrasing?

The phrasing is definitely off. It's saying "V8 creates a single thread for all of JavaScript's execution contexts"

Okay, that matches my experience with V8. Thanks.

Where does the garbage collector run?

I think there are a number of different other threads, it's just the applications call stack that is single threaded.

Maybe it could be rephrased to:

>However, V8 uses an environment of a single thread for all of Javascript's execution contexts.

I think V8 is going to cause JS to overtake Python

JS has become a general scripting language thanks to Node and friends. So you have it with an interpreter that has had so much effort from veterans in JIT VMs versus Python. The writing is on the wall.

At what point did deep dive come to mean high-level overview?

Came here to say the same thing, the title is very misleading. The article even uses those words in the summary: "The goal was to clarify a bit on V8’s structural details (...)", "(...) But these are pretty much the core concepts. (...)".

EDIT: added one more quote.

I kept reading the overview trying to find any place where it took even a shallow dive, but it never did.

which is a shame, since there's a ton of interesting parts inside of v8.

Ok, we've made the title resurface and be an overview above.

Granted, it's higher level than I could have comprehended or desired, but it's lower level than some overviews I can picture.

I think there could be more refinement to the article. The GC does not get rid of "dead or old" objects. It gets rid of dead (unused) objects, regardless of age. The part on inline caching doesn't really explain what happens when the cached method is not the right one. These things could be edited without changing the level of detail very much.

> The higher the language is, the slower it is. That’s why C and C++ are so much faster, they’re very close to the machine code language: the assembly language.

Wait until you see Rust ;)

> That means that new properties can be added, replaced and removed during execution time. This is not possible with languages like Java, for example, in which everything (classes, method, objects and variables) must be defined before program execution and can’t be dynamically changed after the app starts.

Nit: they can; this is just not normally done

> At the time of writing this article, the GitHub repo counts 15.3k stars and 2.9k forks.

Note that V8 is developed mostly outside of GitHub.

> Wait until you see Rust

Rust is still just a really nice macro assembler.

Err, what?

Like every compiled language :/

> Wait until you see Rust ;)

Or Common Lisp. Or OCaml. Or Haskell. Or Dylan. Or...

Those are all higher languages however they are slow.

No, they aren't. That's the whole point. This idea that high level languages are slow is a pernicious myth.

How can say lisp, a language that touches the heap profusely, be faster than c or rust?

i've heard a lot about SBCL and the efficient machine code it generates. i'm guessing a lot of the heap stuff can be optimized away if the code is written right (e.g. via escape analysis or eliminating intermediate values). though i'm guessing that if you really want the best performance, you just end up writing C/Rust with a lot of parentheses :)

You have to compare apples and apples. Lisp can "touch the heap profusely" but it doesn't have to. You can trade off programming convenience for heap touching.

But GC technology has come a very long way, and GC's optimized for Lisp's particular pattern of heap touching have become exceptionally good. Such technology is now standard equipment in EVERY language EXCEPT C and C++, and even C and C++ have them as bolt-on accessories. For some kinds of tasks, Lisp can actually be faster than C or C++. This is why, for example, the Orbitz search engine was written in Common Lisp.

OK can I see some numbers?

Sure. What kind of numbers would you like to see?

That show that lisp is comparably fast as c.

The class of problems you can solve with a C program that doesn't touch the heap profusely is small. C programs that touch the heap profusely often do it in bad ways which are necessary so that they can be debugged to production. For instance, a commonly seen design decision in C programs is to avoid sharing objects, leading to increased memory use, increased calls to malloc and wasteful copying overhead. A Lisp program rarely calls the equivalent of strdup for instance; you don't worry about who is going to free this, and will two modules try to do it to the same object?

Not only that, with languages like Objective-C or C++, one can have high level code just like Python, Lisp or OCaml, yet the myth still stays.

Reply on news.ycombinator.com