Leszek

Comparing a 1 hour flight to a 3-4 hour train journey by those times alone is somewhat dishonest: it doesn't take into account the rest of the journey to/from the airport at either end (usually further out of the city than the main train station), nor the 1-2 hour early arrival at the airport for bag drop/security/killing time at the gate.

Not to mention inconveniences like lack of liquids in hand luggage, expensive airport amenities (should you choose to use them), passing through the security theatre, and of course the actual cost of getting to the airport (in the UK, this can be more than the flight!).

Note that the "existing" baseline compiler is now removed, and entirely replaced by the interpreter.

Ignition is very tightly coupled to the rest of V8, starting with that fact that it uses inline caches and the object model to maintain performance, and finishing with it itself being written in "CSA", which is an assembler DSL that is passed through the TurboFan (optimizing compiler) backend to generate the machine code for the bytecode handlers (this has the interesting side-effect that porting V8 to a new platform requires porting the optimizing compiler). There's not really much that can be split off.

There's no requirement for the bidding to be natural, there are plenty of artificial bidding systems -- the only constraints are that the bidding system you are using must be known to your opponent (to enforce this, I believe that on a bid your opponent can ask your partner what this bid is supposed to communicate), and that you do eventually have to play your bid so it can't match your cards too badly.

This reminds me a lot of the following xkcd comic: https://xkcd.com/1262/

Just a wrapper around gperf:

https://cs.chromium.org/chromium/src/v8/src/parsing/keywords...

https://cs.chromium.org/chromium/src/v8/tools/gen-keywords-g...

We recently started using perfect hashing in V8's parser, also with measurable performance improvement (even over what we had previously, a first character jump table followed by linear search). It's always nice to apply that computer science education to a real world problem.

It'd also be interesting to explore other optimisation metrics, e.g. having common letters on the ends to allow the user to 'blindly' move the pointer to one end or the other without a need for precision.

I'm also curious if e.g. 10 shifts is twice as bad as 5 shifts, it feels to me like there's a drop-off in shifting cost after one shift.

So does V8, albeit with a different calling convention than the surrounding C frames.

I believe there's some things your have to do such aren't C compatible, e.g. store fat pointers of base+length+offset instead of raw pointers, to catch OOB accesses.

I guess you could make pipe variadic:

    function pipe(val, ...funcs) {
      for (let f of funcs) val = f(val);
    }

EDIT: seems like I got ninja'd by an edit :)

Indeed, and this is in a video game, where swapping in a different character model and audio into an identical scenario is reasonably cheap, and thus can be done for many decision. Trying to do the same thing with real actors and re-filming scenes based on choices feels... harder.

Not to mention, the recently gone bankrupt Telltale, which suffered from decisions that claimed to make a difference to the story, but which really did nothing to the overarching plot (e.g. you choose to save character A instead of B, A is soon killed anyway).

Fair enough, thanks for the correction.

As I understand it, this was the premise of cable TV - pay for your cable, and in return you get no ads. Yet, here we are with ads on cable, because it turned out to be more profitable to both charge and show ads than just do one or the other.

High school physics experiments are somewhat of a different case, as "wrong but truthful" results are probably evidence of an incorrectly performed experiment, performing which correctly is part of what one is assessed on. That, or bad luck, but presumably the experiments are sufficiently simple that performed correctly they all but guarantee a "correct" result.

Maybe this will finally end the myth that "you can be rude and insulting as long as you're right" that people seem to attribute to Linus's outbursts

In that V8 makes heavy use of inline caches

Once Node pulls in this version of V8, sure.

This article feels like it ends right when it begins, hinting that these fossils exist but never really diving into what they are, who researches them, how the etymologies are determined, or really anything aside from, as they call it, "fleetingly arresting cocktail-party diversions".

One man's competency is another man's elitism

Sounds like you're describing a new protocol.

I believe so, in this baseline implementation. In fact, that's also true of operations on doubles (non-Smi) in unoptimized code, which are stored as "heap numbers". Avoiding these allocations is one of the things an optimizing compiler can do (and does do, for doubles).

That said, for short-lived BigInts, the allocations may not be as expensive as you might think, since the garbage collector is generational and short-lived objects won't leave the nursery.

Can I ask what such city you found?

This particular engine, V8, doesn't use NaN-boxing, because of the memory costs on 32-bit systems of using 64-bit values for boxed pointers. Instead, we use pointer tagging, relying that with word alignment, we have 2 bits free at the bottom of pointers.

If the lsb is unset, then the remaining 31 bits represent a "small integer", a.k.a. a Smi (on 64-bit, the top 32 bits make the Smi, so that they can be read out of memory with a normal 32-bit access).

If the lsb is set, then the remaining bits are the pointer, where the bottom bits have to be masked off to actually dereference it (practically, most accesses are offset-based field accesses anyway, so we just subtract 1 from the field offset). The other bit, the 2nd lsb, has recently started being used as a weak pointer marker.

So, the type tag isn't stored in bits of the pointer, but rather in the object being pointed to, not dissimilar to a vtable. This has the side-advantage that we can swap the type of an object in-place, without having to update pointers to it. BigInts are immutable, so they are stored as a heap object which holds the object tag (actually another pointer to a "map", that's a story for another time), a bitfield that stores sign and length, and then data inline (very similar to how we store strings).

(pointer|0x1) -> [BigIntMap, bitfield (length+sign), digit0, digit1, ...]

It'd be interesting to revisit that project with wasm rather than asm.js.

Good question: unfortunately not. We only really generate machine code for hot, optimized functions, using TurboFan (all the other machine code, like builtins and the interpreter, is loaded from the "snapshot"). This code is pretty execution specific, and will include things like constants, raw pointers, logic specific to the hidden class transition trees, etc.. Relocating this when serializing/deserializing a cache would be expensive, and we'd probably have to also serialize half the state of the current VM heap, so it would overall be a net loss.

Additionally, our current caching is only after initial top-level execution, where hopefully[0] you haven't run enough code for it to be hot yet, so there wouldn't be any optimized code to cache anyway.

[0] I say "hopefully" because getting code hot during initial execution would usually mean that execution is stalling the main thread at startup, which isn't great.

Agree to disagree on this being a universal 'abstract' gender neutral pronoun problem, and not being profession related.

V8 engineer here: basically, a serialized walk through the object tree, starting from the top-level script. Predominantly, this means bytecode, scoping metadata, and strings.

Perhaps that's something you should evaluate about yourself then, because I don't think you'd raise the same ParseError if the profession were "nurse". Unconscious biases don't have to be malicious to exist, and I catch myself thinking the way you describe sometimes before realising "wait, this should be fine though".