mraleph

18 ms·

121.
by mraleph 12y ago
On 64bit architectures V8 promotes at 32bits. (and if we talk about optimizing compilation things are getting more complicated as there int31, int32 and float64 can all coexist and you can have 31-bit integer stored in a float64 value - if
122.
by mraleph 12y ago
Add 2 more characters in f3 (e.g. two empty spaces in the before return). Right now the way it's written it's still below the limit. That however does not mean you need have to minify your server code. Please don't base suc
123.
by mraleph 12y ago
For context, this is https://code.google.com/p/v8/issues/detail?id=3354 JSPerf test case has misleading name: it has nothing to do with inline caching , but it is indeed related to inlining heuristics . V8
124.
by mraleph 12y ago
As I said, we have intermediate language, but we don't accept it from outside of VM (for now).
125.
by mraleph 12y ago
> I work on integrating into Dart ecosysem "foreign functions interface" (ffi). Truly efficient FFI has to be part of the VM, you can't implement efficient FFI from outside. > - I access data (by physical address) alloc
126.
by mraleph 12y ago
> I have the following methods (via macro defs) in my "native extension": Can't you just expose the data you are reading as an external typed data array to the Dart code? That would remove any need for those methods. >
127.
by mraleph 12y ago
> I think that Dart VM and Dart developers does not like annotations because they thinking that VM cannot use them effectively (even if they written by humans). The fear is actually completely opposite: people would misuse these annotati
128.
by mraleph 12y ago
> If Dart VM can use "patch class" declarations then why this "@inline" should be considered as a bad? Annotation like that is not enough for intrinsics. You would still need to provide some way of detecting in the co
129.
by mraleph 12y ago
What do you want to compare it on? "Using asm.js" is not some magic that just makes all JavaScript faster. For example all those benchmarks from http://dartlang.org/performance are written in a normal JavaScript
130.
by mraleph 12y ago
> V8 VM optimized for that (type dynamics). > Dart VM has a lot problem with performance with this dynamics This claim is substantially false. Where are you deriving this "Dart VM has a lot problem..." from? (feel free to re
131.
by mraleph 12y ago
afaik issue tracker stays
132.
by mraleph 12y ago
> Github has some nice features that chromium.googlesource.com lacks, like being able to list all of the commits that have changed files in a specific sub directory. fwiw you can do this on chromium.googlesource.com as well. look for lin
133.
by mraleph 12y ago
No. V8 has moved to Chromium's Git infrastructure, not GitHub. https://chromium.googlesource.com/v8/v8.git
134.
by mraleph 12y ago
> I'll try rerunning the bench by adding calls to cross-product to see how it fares. btw, if you have a moment I would really appreciate if you tell me how to reproduce +Brandon Donnelson results. It's hard to figure out from t
135.
by mraleph 12y ago
> It uses a lot of polymorphism Are you sure? I have never looked at Java implementation of Box2D used in this benchmark, but Dart version is definitely not that polymorphic in its hottest function which corresponds to this Java one: h
136.
by mraleph 12y ago
LuaJIT1 compiler was also pretty basic in the way it worked - it did not do any major speculative optimizations afaik, so comparing LJ2 interpreter against it is not of much interest. Now check out performance graphs of LuaJIT2 compiler+int
137.
by mraleph 12y ago
This was back in 2010 when V8 did not really have an optimizing compiler - V8's "compiler" was a baseline one essentially gluing together individual interpretation patterns. Also any cross-language comparison should be done v
138.
by mraleph 12y ago
This talk is not about "transpiling" Smalltalk to JavaScript. Smalltalk is just used as a handy example to drive the presentation. I have added the slide to avoid confusion.
139.
by mraleph 12y ago
Sorry for this, I have re-enabled visual controls for the deck. Though swiping should have worked too.
140.
by mraleph 12y ago
in the context of V8 "x87-platform" means "x87-only for floating point" as opposed to normal ia32 platform where V8 assumes SSE2 is present. It's implemented as a separate platform port, not as a bunch of if's
141.
by mraleph 12y ago
That actually can be easily fixed on top of V8 - as V8 already sprinkles stack overflow checks you can make actual fiber stack smaller and expand it on demand.
142.
by mraleph 12y ago
Isn't Shumway more of a confirmation for my concern than a counter example? Shumway is running ActionScript which is extremely close to JavaScript semantically though somewhat more strict and allows for optional typing.
143.
by mraleph 12y ago
Up until recently due to some issues with build scripts and MSVC parameters our bots building 64-bit SDK on Windows were just silently building 32-binaries. I have fixed[1] it couple of weeks ago, but my fix did not make it into 1.5. Sadly
144.
by mraleph 12y ago
Here is a question to consider: can the web where you can't efficiently[1] implement any dynamic language with a semantics different from JavaScript be called truly open? [1] I am well aware about different attempts to attack this issu
145.
by mraleph 12y ago
Caveat: if you see numbers in the range of 1,500,000,000 that means your code was thrown away by the optimizing compiler. Microbenchmarks like that require a lot of care to measure something correctly. Check out my talk from LXJS2013 for mo
146.
by mraleph 12y ago
You can version manually or automatically in the optimizing compiler inner loops of those builtins depending on the denseness / representation of the array backing store. Something along this lines: http://gist.io/70500
147.
by mraleph 12y ago
> That should give you somewhere around 2 times slower performance, or better, not 264 times slower (and with very little effort). You are comparing different ratios: munificent was comparing against JS and your "2 times" predi
148.
by mraleph 12y ago
TypeScript benchmark is one of the Octane benchmarks that does not do warm up, so Crankshaft does not have chance to fully shine [which is totally fair given how TypeScript compiler is used: you don't warm it up, you just spawn it agai
149.
by mraleph 12y ago
> 3) V8 garbage collection is terrible. Creating lots of small object copies has a massive overhead (Compared with, say, the JVM, which has virtually no overhead) Care to elaborate on this, what kind of GC overhead are you seeing when cr
150.
by mraleph 13y ago
> None of V8 .. do allocation removal This is not correct. V8 does sink allocations into deoptimization exits. It does not sink allocations out of the loops at the moment though. > I think it is unknown how to do this well in method J

More ›