Why the New V8 Is So Damn Fast

Post by topaxi » Tue, Jul 31, 2018, 2:23 PM UTC

mort96 wrote: post #194

_0w8t wrote: post #174

Earlier quoted context omitted.

In JS for-in loop enumerates keys in the insert order. So {x,y,z} is different from {z,x,y}

AFAIK, that's not true; the spec doesn't guarantee that it iterates in insertion order, it's just how it's commonly implemented in browsers.

Post by ernst_klim » Tue, Jul 31, 2018, 3:04 PM UTC

weberc2 wrote: post #213

ernst_klim wrote: post #207

Earlier quoted context omitted.

>Not sure what you mean by imprecise It's a rigid term: https://en.wikipedia.org/wiki/Tracing_garbage_collection#Pre... perf shows how much time does GC eat, and that's quite a lot. Thus in the majority of benchmarks go lags behind java or on par with it at best. >there is so much less garbage than in other GC languages That is not true since strings and interfaces are heap allocated thus the only stack allocated obj…

> It's a rigid term Ah, neat! I learned something. :) You’re mistaken about only numbers and simple structs being stack allocated. All structs are stack allocated unless they escape, regardless of their contents. Further, arrays and constant-sized slices may also be stack allocated. I’m also pretty sure interfaces are only heap allocated if they escape; in other words, if you put a value in an interface and it doesn’…

    func main() {
            x := 42
            fmt.Println(x)
    }

    ./main.go:7: x escapes to heap

Post by weberc2 » Tue, Jul 31, 2018, 3:25 PM UTC

yxhuvud wrote: post #126

weberc2 wrote: post #111

Earlier quoted context omitted.

It’s not native vs VM, but rather “has stack semantics/value types” vs “no stack semantics/value types”. In particular, OCaml’s standard implementation is a native, not VM. Also worth calling out Go, which is rather unique in that it has stack semantics but it also has a garbage collector, so it’s kind of the best of both worlds in terms of ease of writing correct, performant code.

Regarding your last point, Crystal has the same features as go in that regard, while at the same time being vastly more expressive. This mostly due to the standard library in Crystal being so nice for work with collections (which perhaps isn't surprising as the APIs are heavily influenced by Ruby). Blocks being overhead free is another necessary part for this to work well.

Post by weberc2 » Tue, Jul 31, 2018, 3:42 PM UTC

ernst_klim wrote: post #214

weberc2 wrote: post #213

Earlier quoted context omitted.

> It's a rigid term Ah, neat! I learned something. :) You’re mistaken about only numbers and simple structs being stack allocated. All structs are stack allocated unless they escape, regardless of their contents. Further, arrays and constant-sized slices may also be stack allocated. I’m also pretty sure interfaces are only heap allocated if they escape; in other words, if you put a value in an interface and it doesn’…

Both arrays and interfaces are heap allocated. Slice is just a pointer to a heap allocated array. Structure could be stack allocated, but any of it's fields would not if there is anything but a number. A trivial example: https://segment.com/blog/allocation-efficiency-in-high-perfo... func main() { x := 42 fmt.Println(x) } ./main.go:7: x escapes to heap So a trivial interface cast leads to allocation.

    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

    BenchmarkEscapeArray-4  50000000   21.3 ns/op  0 B/op  0 allocs/op

    BenchmarkEscapeStruct-4  100000000  12.8 ns/op  0 B/op  0 allocs/op

    type Inner struct {
    	Slice  []int
    	String string
    	Int    int
    }
    
    type Struct struct {
    	Int    int
    	String string
    	Nested Inner
    }
    
    func (s Struct) AddThings() int {
    	return s.Int + len(s.String) + len(s.Nested.Slice) + len(s.Nested.String) +
    		s.Nested.Int
    }
    
    func BenchmarkEscapeStruct(b *testing.B) {
    	for i := 0; i