Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Birth and Death of JavaScript [video]

destroyallsoftware.com

Post reply on HN
Print view View original

101–110 of 236 posts

Re: The Birth and Death of JavaScript [video]

#101

Post by [deleted] »

gary_bernhardt wrote: post #88
nteon wrote: post #75

Earlier quoted context omitted.

On linux, system calls don't result in a TLB flush - kernel data structures and code are in a different portion of the virtual address space (starting from the top of VM memory, if I remember right) that is tagged as not being available from ring 3. So system calls are quite fast. EDIT: Kernel memory begins at PAGE_OFFSET, see here: https://www.kernel.org/doc/gorman/html/understand/understand... Kernel memory lacks t…

I didn't know that! It certainly makes sense. Context switches still thrash the TLB, though. The performance cost of that has gotten better as time has gone on, but I wonder how many transistors (and how much power) CPUs are burning for that mitigation. The "how computers actually work" digression originally had a section on context switches, but I removed it early on because I felt like that section was dragging. To…

[deleted]

Re: The Birth and Death of JavaScript [video]

#102

Post by Iftheshoefits »

djur wrote: post #90
oscargrouch wrote: post #87

Earlier quoted context omitted.

with a function named "parseInt" anyone would expect the inputs as base 10.. otherwise this shoud be called "parseHex" for 15 or at least "parseBytes(input, base)" The programmers are not the ones to blame on that.. this is really a bad contract between the language and the programmer Its the equivalent of a function named "getStone()" to return you a " Paper{} " :)

"int" doesn't imply anything about the base.

It does for human beings. We use base-10 for basically everything. This is true even for most programmers in most situations. Human beings aren't computers, and we aren't abstract math processing units who by default consider numbers abstracted (e.g. as elements of Rings). This goes double for string representations of numbers--in the majority of cases a number represented by a string is a number meant for human consumption in a normal human context; not some machine running in base-2 (or -8 or -16). It is certainly reasonable to expect "parseInt" to parse an integer out of a string in base-10 by default, and entirely unreasonable to expect to be required to provide a base as anything except an optional argument, and certainly it is unreasonable to expect that that second optional argument is treated as not optional in a composition operation.

Re: The Birth and Death of JavaScript [video]

#103

Post by pookiepookie »

I'm not sure I understand the claims toward the end of the talk about there no longer being binaries and debuggers and linkers, etc. with METAL.

I mean, instead of machine code "binaries", don't we now have asm blobs instead? What happens when I need to debug some opaque asm blob that I don't have the source to? Wouldn't I use something not so unlike gdb?

Or what happens when one asm blob wants to reuse code from another asm blob -- won't there have to be something fairly analogous to a linker to match them up and put names from both into the VM's namespace?

Re: The Birth and Death of JavaScript [video]

#104

Post by nly »

gary_bernhardt wrote: post #88
nteon wrote: post #75

Earlier quoted context omitted.

On linux, system calls don't result in a TLB flush - kernel data structures and code are in a different portion of the virtual address space (starting from the top of VM memory, if I remember right) that is tagged as not being available from ring 3. So system calls are quite fast. EDIT: Kernel memory begins at PAGE_OFFSET, see here: https://www.kernel.org/doc/gorman/html/understand/understand... Kernel memory lacks t…

I didn't know that! It certainly makes sense. Context switches still thrash the TLB, though. The performance cost of that has gotten better as time has gone on, but I wonder how many transistors (and how much power) CPUs are burning for that mitigation. The "how computers actually work" digression originally had a section on context switches, but I removed it early on because I felt like that section was dragging. To…

What you seem to be missing with re: asm.js is that, while the JIT to native code gets you your super-fast integer operations, it's still critically incomplete with regard to memory access. Every single individual memory access has to be bounds checked or pushed through some other indirection inside the runtime. Google demonstrated similar ideas with NaCl, which achieved safety with a similarly restricted native code and a just-in-time verification step. Even if these memory accesses could be made as efficient as those performed by the CPUs access protection, you're still not gaining anything you don't already have.

Regarding context switches: A full CPU context switch on x86 (not to ring1 but between two arbitrary points within a single userland address space) takes a few dozen instructions and about 40-80 cycles. A single cache-line miss resulting in a load from main memory on the other hand takes at least twice that (~200 cycles). Again, hits from jumping around in memory will dominate.

How significant is a 20% overhead from virtual memory? Probably about the same as getting 1% more of your memory accesses back in to high level caches.

Re: The Birth and Death of JavaScript [video]

#106

Post by andhow »

nly wrote: post #104
gary_bernhardt wrote: post #88

Earlier quoted context omitted.

I didn't know that! It certainly makes sense. Context switches still thrash the TLB, though. The performance cost of that has gotten better as time has gone on, but I wonder how many transistors (and how much power) CPUs are burning for that mitigation. The "how computers actually work" digression originally had a section on context switches, but I removed it early on because I felt like that section was dragging. To…

What you seem to be missing with re: asm.js is that, while the JIT to native code gets you your super-fast integer operations, it's still critically incomplete with regard to memory access. Every single individual memory access has to be bounds checked or pushed through some other indirection inside the runtime. Google demonstrated similar ideas with NaCl, which achieved safety with a similarly restricted native code…

On x64 in Firefox, at least, there are no bounds checks; the index is a uint32; the entire accessible 4GB range is mapped PROT_NONE with only the accessible region mapped PROT_READ|PROT_WRITE; out-of-bounds accesses thus reliably turn into SIGSEGVs which are handled safely after which execution resumes. Thus, bounds checking is effectively performed by the MMU.

Re: The Birth and Death of JavaScript [video]

#107

Post by hetid »

gary_bernhardt wrote: post #93
vor_ wrote: post #78

Earlier quoted context omitted.

The second JavaScript example, when he told someone in the audience, "No, that's just an object." It was a string.

I knew that it was a string. If you listen closely, you'll hear that he asked "is that an array of object?" He probably asked that because it's in square brackets. I said "No, it's just an object". I've probably seen twenty people call this "wrong", which frustrates me. It's not wrong. It was a stringified object! I didn't say "stringified" because it wasn't relevant to the question of whether the object was in an ar…

It's only 15 commas man, 15 commas. That extra comma could kill someone.

Speaking of which, why does WAT do different things on node.js?

Re: The Birth and Death of JavaScript [video]

#109

Post by [deleted] »

pookiepookie wrote: post #103

I'm not sure I understand the claims toward the end of the talk about there no longer being binaries and debuggers and linkers, etc. with METAL. I mean, instead of machine code "binaries", don't we now have asm blobs instead? What happens when I need to debug some opaque asm blob that I don't have the source to? Wouldn't I use something not so unlike gdb? Or what happens when one asm blob wants to reuse code from ano…

[deleted]

Re: The Birth and Death of JavaScript [video]

#110

Post by MichaelGG »

liviu wrote: post #108
jliechti1 wrote: post #17

For those unfamiliar, Gary Bernhardt is the same guy who did the famous "Wat" talk on JavaScript: https://www.destroyallsoftware.com/talks/wat

Brendan Eich covered this subject at O'Reilly Fluent conference in 2012: http://youtu.be/Rj49rmc01Hs?t=5m7s

If by cover you mean he essentially shrugs and says "it was the 90s" and moves on to ES6.
Post reply on HN