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

Why the New V8 Is So Damn Fast

nodesource.com

Post reply on HN
Print view View original

221–230 of 237 posts

Re: Why the New V8 Is So Damn Fast

#221

Post by stcredzero »

FridgeSeal wrote: post #109
stcredzero wrote: post #69

Earlier quoted context omitted.

I used to work for a Smalltalk vendor. It was even better than that. For awhile we had the hottest JIT virtual machine. Smalltalks that followed the original design ran bit identically across multiple platforms. At one point, Squeak Smalltalk was running bit identically across 50 combinations of CPU and OS, and Squeak and its descendants probably can run bit identically across several times that number of environment…

Wow that sounds super, super cool! As you say, I really wish tech had followed that route, think of all the cool things we'd have.

Picture it. Now, go and build it on top of what we have today!

Re: Why the New V8 Is So Damn Fast

#222

Post by mamcx »

eksemplar wrote: post #162
mamcx wrote: post #86

Earlier quoted context omitted.

> respect Not much respect, but more acceptance as a unavoidable language to use that thanks of millons of $$$$/human-hours of effort to polish it... is ok-ish.

You don’t achieve acceptance without a level of respect that comes from being useful. JS is really one of the most useful languages today. You can argue whether everything moving to web apps (and I may be using the term web apps wrong, but I’m speaking about anything that runs in a browser) is such a good idea, it’s probably not, but it’s whats happening because it’s really fucking awesome in terms of getting things…

> You don’t achieve acceptance without a level of respect that comes from being useful

But this is not the case of JS. JS is used because is the only posibility on web. Imagine if cobol was the only posible language to code on any desktop, and any other MUST transpile to it.

Just by force of necessity, Cobol will get nicer. But not because is respected, is because WHAT OTHER OPTION YOU HAVE?

JS eventually migrate to servers and get easier to integrate? Well that is the same with Lua and others that are even nicer.

But anyway. JS win for market brute force.

Re: Why the New V8 Is So Damn Fast

#223

Post by weberc2 »

ernst_klim wrote: post #220
weberc2 wrote: post #218

Earlier quoted context omitted.

Looks like you're right about interfaces (full benchmark source code: https://gist.github.com/weberc2/87d2fdc379065a2765d1c9f490ad... )! BenchmarkEscapeInterface-4 50000000 33.3 ns/op 8 B/op 1 allocs/op BenchmarkEscapeConcreteValue-4 200000000 9.45 ns/op 0 B/op 0 allocs/op BenchmarkEscapeConcretePointer-4 100000000 10.0 ns/op 0 B/op 0 allocs/op But arrays are stack allocated: BenchmarkEscapeArray-4 50000000 21.3 ns/o…

I'm sure your strings are not stack allocated, they are statically allocated (and would be statically alocated in any language). Not sure about arrays, but dynamic arrays should be dynamically allocated do, your arrays are static probably. They would be heap allocated, if you would use make.

It doesn't matter whether they're stack allocated or statically allocated; neither is garbage, contrary to the original claim ("Go generates a lot of garbage except when dealing with numeric code"). The subsequent supporting claims ("structs with non-numeric members are heap-allocated", "struct fields that are not numbers are heap allocated", etc) were false (sometimes non-numeric members are heap allocated, but they're often not allocated and never because they're non-numeric and their container is never heap allocated on the basis of the location of the member data).

I think this matter is sufficiently resolved. Go trades GC throughput for latency and it doesn't need compaction to get good cache properties because it generates much less garbage than traditional GC-based language implementations.

Re: Why the New V8 Is So Damn Fast

#224

Post by ernst_klim »

weberc2 wrote: post #223
ernst_klim wrote: post #220

Earlier quoted context omitted.

I'm sure your strings are not stack allocated, they are statically allocated (and would be statically alocated in any language). Not sure about arrays, but dynamic arrays should be dynamically allocated do, your arrays are static probably. They would be heap allocated, if you would use make.

It doesn't matter whether they're stack allocated or statically allocated; neither is garbage, contrary to the original claim ("Go generates a lot of garbage except when dealing with numeric code"). The subsequent supporting claims ("structs with non-numeric members are heap-allocated", "struct fields that are not numbers are heap allocated", etc) were false (sometimes non-numeric members are heap allocated, but they…

>It doesn't matter whether they're stack allocated or statically allocated

It does. Any language could do static allocation, go is not different from java here, the problem is that in any real code nearly all your strings and arrays would be dynamic, thus heap allocated, as well as interfaces. Consider also that allocations in Go are much more expensive than in java or haskell.

Re: Why the New V8 Is So Damn Fast

#225

Post by weberc2 »

ernst_klim wrote: post #224
weberc2 wrote: post #223

Earlier quoted context omitted.

It doesn't matter whether they're stack allocated or statically allocated; neither is garbage, contrary to the original claim ("Go generates a lot of garbage except when dealing with numeric code"). The subsequent supporting claims ("structs with non-numeric members are heap-allocated", "struct fields that are not numbers are heap allocated", etc) were false (sometimes non-numeric members are heap allocated, but they…

>It doesn't matter whether they're stack allocated or statically allocated It does. Any language could do static allocation, go is not different from java here, the problem is that in any real code nearly all your strings and arrays would be dynamic, thus heap allocated, as well as interfaces. Consider also that allocations in Go are much more expensive than in java or haskell.

We're talking past each other. My claim was that Go doesn't need compaction as badly as other languages because it generates less garbage. You're refuting that with "yeah, well it still generates some garbage!". Yes, strings and arrays will often be dynamic in practice, but an array of structs in Go is 1 allocation (at most); in other many other languages it would be N allocations.

> Consider also that allocations in Go are much more expensive than in java or haskell.

This is true, but unrelated to cache performance, and it's also not a big deal for the same reason--allocations are rarer in Go.

EDIT:

Consider `[]struct{nested []struct{i int}}`. In Go, this is at most 1 allocation for the outer array and one allocation for each nested array. In Python, C#, Haskell, etc, that's something like one allocation for the outer array, one allocation for each object in the array, one allocation for each nested array in each object, and one allocation for each object in each nested array. This is what I mean when I say Go generates less garbage.

Re: Why the New V8 Is So Damn Fast

#226

Post by mikermcneil »

nicoburns wrote: post #10
sbjs wrote: post #4

Earlier quoted context omitted.

Just use Express.js or Sails.js, they're 1:1 to Sinatra or Rails. Join us!

Unfortunately Sails is nowhere near as good as Rails. Which is kind of strange given the size of the JavaScript community, and the fact that PHP has Laravel and Python has Django, both of which are comparable to Rails. Amusingly given all the PHP hate, if you want a faster rails-like framework, Laravel might be your best bet.

Have you tried Sails 1.0? (There’s always more to do, but we’re working to improve the framework a little more every day.)

Re: Why the New V8 Is So Damn Fast

#227

Post by ernst_klim »

weberc2 wrote: post #225
ernst_klim wrote: post #224

Earlier quoted context omitted.

>It doesn't matter whether they're stack allocated or statically allocated It does. Any language could do static allocation, go is not different from java here, the problem is that in any real code nearly all your strings and arrays would be dynamic, thus heap allocated, as well as interfaces. Consider also that allocations in Go are much more expensive than in java or haskell.

We're talking past each other. My claim was that Go doesn't need compaction as badly as other languages because it generates less garbage. You're refuting that with "yeah, well it still generates some garbage!". Yes, strings and arrays will often be dynamic in practice, but an array of structs in Go is 1 allocation (at most); in other many other languages it would be N allocations. > Consider also that allocations in…

>Consider `[]struct{nested []struct{i int}}`.

A typical example, yeah. I've said about structs of ints already, it's not a common type unfortunately anywhere beyond number crunching, in which go sucks anyway.

In haskell you could have unboxed array with unboxed records. Check Vector.Unboxed.

Re: Why the New V8 Is So Damn Fast

#228

Post by sbjs »

mikermcneil wrote: post #226
nicoburns wrote: post #10

Earlier quoted context omitted.

Unfortunately Sails is nowhere near as good as Rails. Which is kind of strange given the size of the JavaScript community, and the fact that PHP has Laravel and Python has Django, both of which are comparable to Rails. Amusingly given all the PHP hate, if you want a faster rails-like framework, Laravel might be your best bet.

Have you tried Sails 1.0? (There’s always more to do, but we’re working to improve the framework a little more every day.)

Awesome to see the creator of Sails here! And awesome that you have such a positive and constructive response to criticisms! I see that Sails is also a company and not just an open source project, are you a full time company living off of using your open source work? If so can you give any advice to someone who is trying to learn how to make a living with open source? I am full of energy and passion for software and want to put that towards open source, but it would be much nicer to also get paid while doing so!

Re: Why the New V8 Is So Damn Fast

#229

Post by weberc2 »

ernst_klim wrote: post #227
weberc2 wrote: post #225

Earlier quoted context omitted.

We're talking past each other. My claim was that Go doesn't need compaction as badly as other languages because it generates less garbage. You're refuting that with "yeah, well it still generates some garbage!". Yes, strings and arrays will often be dynamic in practice, but an array of structs in Go is 1 allocation (at most); in other many other languages it would be N allocations. > Consider also that allocations in…

>Consider `[]struct{nested []struct{i int}}`. A typical example, yeah. I've said about structs of ints already, it's not a common type unfortunately anywhere beyond number crunching, in which go sucks anyway. In haskell you could have unboxed array with unboxed records. Check Vector.Unboxed.

> I've said about structs of ints already

Yeah, but you were wrong (you said other kinds of structs would escape to the heap). The innermost struct could have a string member and a `*HeapData` member; it wouldn't matter. The difference in number of allocations between Go and others would remain the same. The difference isn't driven by the leaves, it's driven by number of nodes in the object graph; the deeper or wider the tree, the better Go performs relative to other GC languages.

> In haskell you could have unboxed array with unboxed records. Check Vector.Unboxed.

For sure, but in Go "unboxed" is the default (i.e., common, idiomatic); in Haskell it's an optimization.

Re: Why the New V8 Is So Damn Fast

#230

Post by stefs »

beagle3 wrote: post #183
stefs wrote: post #172

Earlier quoted context omitted.

@JIT vs. AOT: i used to think that, too. but graal came out and got 90% of the JIT speed right from the start with a fraction of the time hotspot had for optimization (and of course, with better startup times).

Yes, it seems Graal might finally deliver on the "JIT is better because it is better informed" promise after 20 years. I'm holding my fingers crossed, but I think we need a little more experience with it before victory can be declared.

uh, a misunderstanding, my mistake. what i meant was that graals native-image AOT compiler with the substrate VM achieves 90% of hotspot JIT execution speed pretty much since the project was launched. you may be right that graals JIT is still faster, i don't know about that.
Post reply on HN