
An overview of V8 - Liriel
https://blog.appsignal.com/2020/07/01/a-deep-dive-into-v8.html
======
wwarner
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-...](https://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-Erik-
Meijer-and-Lars-Bak-Inside-V8-A-Javascript-Virtual-Machine)

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

------
CodeMage
> _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?

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

~~~
amelius
Where does the garbage collector run?

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

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

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

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

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

~~~
lisper
> Wait until you see Rust ;)

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

~~~
adamnemecek
Those are all higher languages however they are slow.

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

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

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

~~~
adamnemecek
OK can I see some numbers?

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

~~~
adamnemecek
That show that lisp is comparably fast as c.

