Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
mraleph
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
25 ms
·
181.
▲
by
mraleph
13y ago
> it's awfully hard to "submit a bug report and pray," You don't need to be praying. If no immediate fix can be made in the V8, you will get some recommendations and explanations based on the V8 team knowledge. I woul
182.
▲
by
mraleph
13y ago
Except that right now you are limited to arithmetic and typed array manipulation. Subset like that is predictable because it is taking away all moving dynamic parts. You become free from questions like "where should I put methods? on
183.
▲
by
mraleph
13y ago
This is actually easy to work around by creating trampolines. Dan Carney creating a small header file with templates to create those trampolines easily: https://github.com/drcarney66/v8-backport Amount of typing one ne
184.
▲
by
mraleph
13y ago
I see, yes just printing a simple function on demand is indeed quite useful. IIRC V8 has Debug.disassemble(f), requires both a special build and mirror debugger exposed to the page. Prints disassembly to stdout. Can be tweaked to return dis
185.
▲
by
mraleph
13y ago
It is true that debugging[1] options are not well documented, however it is also true that they are intended for use only in exceptional cases or by V8 developers. Many of them are not even available in release build of V8 that is shipping
186.
▲
by
mraleph
13y ago
In short it was easy to misuse global v8::Persistent<T>`handles leading to memory corruptions and such. Unfortunately making them safe to use also means making them hard to use directly. Previously they were just interchangeable with
187.
▲
by
mraleph
13y ago
> You can literally get the browser to dump the native assembly it produced when JITting a given function. You can literally get Chrome to dump native assembly it produces when JITting a given function. You just need to build Chromium yo
188.
▲
by
mraleph
13y ago
[disclaimer: I worked on V8] I must say that public facing API is well documented right in the header files. Each class and majority of important functions have long comments[1]. So claiming that V8 has an anti-documenation culture is incor
189.
▲
by
mraleph
13y ago
Yes, I understand what VM implementors can derive from individual results of each and every micro-benchmark. [I usually go as far as saying that only VM implementors and people with deep enough understanding of VMs should ever micro-benchma
190.
▲
by
mraleph
13y ago
> for one primary reason: the transcendental math cache If this is the primary reason then it implies that those benchmarks primarily measure performance of transcendental operations with repetitive arguments and thus nothing interesting
191.
▲
by
mraleph
13y ago
> Perhaps you made some other change. I tried with both global remove and remove on the Array prototype. V8 has recently improved DeltaBlue score by, I think, ~6% so it can be that before this improvement OrderedCollection overhead was m
192.
▲
by
mraleph
13y ago
V8 snapshot is nothing like bytecode, it a serialized native heap with architecture dependent native code (sic!) embedded into it. And it still contains all source code for all functions.
193.
▲
by
mraleph
13y ago
V8 has no internal bytecode.
194.
▲
by
mraleph
13y ago
> This extra level of indirection on every container is very costly in V8 and Ion. It is very costly only if JIT is particularly bad at eliminating redundancies. Crankshaft is not and (I hope) neither is IonMonkey. If you try removing it
195.
▲
by
mraleph
13y ago
Well, this dualism is used to communicate important distinction: single value vs. multiple values, so streams return futures in the places where it is absolutely meaningful to do so e.g. first element of a stream can be obviously viewed as
196.
▲
by
mraleph
13y ago
Unfortunately I am not aware about concrete plans. I also doubt anything large will happen to the language until after 1.0 Right now there are two separate issues in the Dart's bugtracker: one for Futures https://code.google
197.
▲
by
mraleph
13y ago
Added the example to the same Gist: https://gist.github.com/mraleph/5991990#file-example5-dart
198.
▲
by
mraleph
13y ago
dart:async also provides the Stream abstraction that can be compared to Clojure(Script)'s core.async channels. Libraries like dart:html and dart:io express their asynchronous APIs in terms provided by dart:async so the model is unified
199.
▲
by
mraleph
13y ago
Did you actually want to say "OdinMonkey was implemented very quickly, in about a month"? I am not sure I understand what people try to prove or imply when they say that. OdinMonkey takes an extremely limited statically typed lang
200.
▲
by
mraleph
13y ago
Dart is not JavaScript by far. It has very different semantics in its core, unlike TypeScript or CoffeeScript.
201.
▲
by
mraleph
13y ago
V8's GC is both generational and incremental. Generational can be actually viewed as a variation of incremental GC.
202.
▲
by
mraleph
13y ago
OdinMonkey is: a separate front-end for optimizing compiler (one that translates JavaScript code to compiler IR), a couple of IR instructions specific to asm.js (e.g. asm.js heap access), plus AOT linker, trampolines for transitioning to&#x
203.
▲
by
mraleph
13y ago
You can't simply asm.js'fy LuaJIT2 because it has an interpreter hand written in assembly and it generates native code to achieve peak performance. You can only asm.js'fy a normal Lua interpreter which is up to 64x slower than LuaJIT on ben
204.
▲
by
mraleph
13y ago
fwiw V8 always had a generational collector.
205.
▲
by
mraleph
14y ago
> There is hardly any duplication. There will be a clone of JavaScript parser. IR building is already duplicated as well. I am aware that middle-end/back-end are shared, though there are some IR instructions are that specific for asm.js
206.
▲
by
mraleph
14y ago
> Asm.js guys however proved that using the declaration that specifies the very fixed assertions Well, C compilers proved that long ago, nothing novel here. It is obviously easier to compile statically typed languages to efficient code
207.
▲
by
mraleph
14y ago
Nope, that is not what I say. I am saying that if JS VMs already do a lot of optimizations which are not going to disappear anywhere even with "use asm" because they benefit normal JavaScript code. Now if JS VMs solve a range of known i
208.
▲
by
mraleph
14y ago
> - I thought this was obvious: Chrome and normal Firefox are so much slower because they do not explicitly optimize the Asm.js code path. Not everything is obvious here, actually. If we are talking about vertex skinning benchmark where
209.
▲
by
mraleph
14y ago
I think there are incomparable. Dart is not a subset of JavaScript. Dart is dynamically typed. But Dart is more than just a language now, it's ecosystem of tools and libraries.
210.
▲
by
mraleph
14y ago
Yes, I agree with your point. Yet, I see quick edit&refresh as the part of the ecosystem. Hard to enable that without VM. [regarding the disclaimer: I add it for two reasons. First, I have seen people accusing others of hiding their bia
More ›