V8 release v6.8
v8project.blogspot.com
v8project.blogspot.com
I enjoy seeing updates like this to learn more about how the engine works, but: these changes are exactly the reason you _don't_ want to design your code around specific micro-optimizations, particularly when it comes to JS. They're at parity now and it is quite possible that 6 or 12 or 24 weeks from now, the cleaner destructuring approach will actually be faster than the tmp-var approach. Remember this the next time someone suggests in code review that you should design your code to meet the whims of the JS engine.
Just making a joke.
Newer languages with solid type inference help a lot for reducing that cognitive load, so this isn't saying that one side of the static/dynamic-typing debate is wrong but rather that it's an important design factor for programmer productivity.
One can write totally unreadable code in Scala and a totally readable version of the same algorithm in Python if one so wishes.
The two are totally orthogonal concerns.
You can write highly obfuscated spaghetti code from hell in any type checked language you wish...
Disclaimer: I do tend to use for loops a lot since they can be quite readable.
But definitely agree that cleaner code > performance in most cases. First make sure you really do need to squeeze that performance out.
Not arguing you should do such micro-optimizations, but generally writing "simpler" code should also allow less sophisticated compilers to generate fast code.
There's a good argument for both situations depending on context.
I think the best approach, if you have the discipline to follow it, is to normally code for ease of understanding ("clean code"), and occasionally fall back to performance hacks in performance critical code, but don't stop there. The following will likely make you both much more confident that your choices were correct, that you can easily reverse them when needed at little cost, and that you'll know (or be able to easily query) whether that time has come.
1. Mark each performance hack with some identifier (e.g. a comment, /* PERFHACK #4632 / or / PERFHACK #4632 - destructing is slow */.
2. Maintain a test in the same repo which confirms this assertion, by actually testing the relative speed of each approach, expecting the hack to be faster be some margin. Each test should contain the PERFHACK identifier and optionally a description.
3. Occasionally (or along with regular testing) run all these PERFHACK tests, looking for failures, which would indicate the performance is not a certain percentage greater than the simple case.
4. To fix the failing test, reverse the test assertion, and search the codebase for instances of that PERFHACK identifier and fix those as well.
That should at max cause a single test case failure, as it caused a speedup during one leg of the operation benchmark.
Since these are not completely automated (you might want to have them as a set of allowed to fail tests, or tests you have to explicitly request), you can easily just re-run the tests to confirm the prior output wasn't a fluke. You need something like that anyway because you're essentially testing benchmark outputs, and it's not like it's easy to set up perfectly consistent benchmarks in the first place.
The margin of margin you want your PERFHACK to be faster than the default code is also your margin of error. Theoretically you would test something like NORMAL_SECONDS*0.8 > PERFHACK_SECONDS in your test to ensure you're still getting a 20% or more speedup. If some changes cause it to drop to 15%, you then get to assess whether that gain is still worth the hack (and perhaps change the test to be a 10% gain assertion), or whether you want to clean up your code (or at least schedule it).
The point is that you've put a system in place that allows you to have a clearer picture of whether your prior decisions with regard to performance hacks still make sense.
V8 improvements also benefit NodeJS, and they also contribute to it, I think.
I use both Chrome and NodeJS and will take any speed improvements they make.
For types to help with optimization, those types have to be correct and reliable (i.e. sound). If every line of your app and all of its dependencies are sound, then you should expect a speedup. If there is any unsound code, then you'll have to generate runtime checks to preserve the soundness properties that your optimizer assumes, and those can actually result in _slower_ code.
Even Flow has made compromises that are good for a type checker, but likely unacceptable if an optimizer is relying on them. Quoting https://flow.org/en/docs/lang/types-and-expressions/
> Soundness is fine as long as Flow isn’t being too noisy and preventing you from being productive. Sometimes when soundness would get in your way too much, Flow will favor completeness instead. There’s only a handful of cases where Flow does this.
https://github.com/mbasso/asm-dom
You can already call out to small JS code snippets that work on the DOM from WAM, and since DOM manipulation is slow anyway, the small overhead you get for calling into JS won't make a difference. So I'd say, go ahead and manipulate the DOM from WASM, even if WASM supports direct DOM access later it won't make much of a difference (apart from slightly less and cleaner code in the DOM-access library).
What might happen instead is that there will be a sudden burst of front end languages running on WASM, which will allow some front end people to completely avoid Javascript.
It's hard to predict what the adoption of those languages will look like, there's a million factors in play and few of them are technical.
The other great thing is that WASM libraries written in all sorts of languages will be available to all of them.
And finally, to appease your OO concerns, in fact... I became progressively annoyed by the state of the web as it seemed to make heavy adoption of OO patterns (thinking angular). The ML family of programming languages has offered a much better software development experience in typed programming languages since the 1970s. There are already several compilers for those languages targeting JavaScript which are only waiting to target WASM. (WebSharper for F# & C#, ocsigen for OCaml, Scala.js for Scala, I'm sure plenty others).
JavaScript was conceived as Lisp with all the good parts removed. Note that ClojureScript is a delivery of Lisp that target JavaScript. I'm not a Clojure developer myself but I would have to agree that Clojure developers seems to be the most productive programmers out there.
For example, the API between your language and the other language is probably not going to match your languages style. You see it all the time with APIs that seem to be written for java but are in another language.
If the library has to write different APIs for all the different langauges, then that is an additional cost.
Then there is the fact that less people will know a "standard" language, because they will all be using different languages, so they can't contribute back to the libraries that they use so easily. For example, if I am using a scala library and want to change something or commit a bug fix or whatever, I will have to learn scala.
Your second point is fair, however I think programmers tend to stick to their "favourite programming language" like a religion and fail to appreciate that learning a new programming language can be done in 2 weeks while learning the ecosystem of libraries of a platform is a multi-year endeavour. In particular, you'll be able to carry your knowledge of all the WASM libraries you've learned to love when you decide to make a switch from say JS to XXX.
I've been writing Python for longer than I've been writing C#, but I'm nowhere near as productive in Python.
As for the second, there's zillions of things that can explain that and I'm definitely not clear that your being less productive in Python than in C# has anything to do with how much time you've spent on either. Which is the whole point, programming languages aren't equal. Neither are libraries.
If you set aside the time to learn the libraries and narrow it down only to syntax, that certainly the time to learn it will vary from person to person but isn't a multi-month task for anyone. I think you are scoping it in the larger context of non-shared libraries.
The best example I could give would be learning VB.NET when you already know C# (or vice versa).
For basic support these languages need support for GC - some degree of stackwalking if they don't want to use shadow stacks. That support should be coming soon.
But you can't get around the fact that you need to ship a runtime to support these languages, so you're not just shipping your code, but the runtime required to run it.
But a runtime alone doesn't give you fast execution - you need to jit. And JITs require a lot of deep access into the architecture. You need to be able to generate and inject executable code into the program. You need to be able to patch code at runtime. For security purposes you'd ideally like a separate process that manages the codegen to provide fast w^x support for jitcode.
For the forseeable future, any real dynamic language support on the web will require direct runtime support, namely the regular JS engine.
Disclaimer: I'm a JS JIT developer at Mozilla, have worked on the IonMonkey optimizing compiler and did a good chunk of the design and implementation of our baseline JIT.
I'm excited at the prospect of wasm being a portable, tight runtime that'll eventually be a good cross-platform target for writing dynamic language, but there is quite a bit of infrastructure required within wasm before it can support that.
I thought the idea was to mostly use WebAssembly for parts that are performance critical, not replace all of it?
A UI framework developed exclusively for canvas-apps could probably add many such features.
I am yet to have worked in any web project where stuff like ARIA was even on the requirements list.
In the future machine learning will be applied to detect and disable ads visually.
JavaScript however is in a way similar to PHP and I'd say more dangerous as, unlike PHP it doesn't have a ugly syntax to warn you.
I've been working in the JS ecosystem lately and suddenly crazy knowledge from my life as PHP programmer turns out to be useful:
- adding statements above a function or a class? No problem: will be run on loading the file just line in PHP.
- == not checking if things are equal? Just use === like in PHP
Thst said I'm really impressed with the ecosystem. It is just JavaScript the language that needs to be replaced.
I guess that is either the "shoot the messenger strategy" or what I said was so horribly wrong I should have seen it myself.
Whoever wonders which one is true can verify for themselves that except for the syntax modern PHP and JavaScript are surprisingly similar: )
The challenges to offering a direct DOM api are numerous. The DOM API uses the full complement of javascript types; whereas WebAssembly only has integers. So you need to either standardize a binary representation of javascript objects, arrays, functions, pointers, etc., or you need to modify all the hundreds of API calls to use different semantics, e.g. a C-style string for a node name, a wasm function-table index for a callback.
References of all kinds would be a huge sticking point, especially with garbage collection involved. If you store them c-style as integers, then how do you dereference them safely, or what if you add 50 to a reference etc. If they're stored as opaque references then that's an entire new system added on to wasm.
All of this could be done in theory, but I don't see it happening with WebAssembly. WebAssembly is a deliberately conservative and simple project. It was partly a reaction to the more aggressive NaCl project which had threads and its own low-level API pepper etc. WebAssembly is moving at the glacial pace typical of browser consensus, and the stakeholders involved don't actually want it to take over the web ecosystem (Apple doesn't want web apps to be as good as App Store apps; Google doesn't want opaque web apps that can't be easily injected with ads and analytics; Mozilla doesn't want the browser to be a simple, commodity VM).
You can find the proposal here: https://github.com/WebAssembly/host-bindings/blob/master/pro...