41–50 of 78 posts
Oh. Dear. God. JavaScript is going to become the x86 of our time, i.e., the historically awful patchwork of kludges that gets passed onto each generation to kludge anew which also runs the entire world. JavaScript: we don't have integers, but, dammit, we have vector instructions. FML. Maybe it's not too late to take up painting.
https://www.kickstarter.com/projects/gfw/espruino-javascript...
This is what programming is now.
Earlier quoted context omitted.
I liked the "original" assembly more, at least it was designed for helping humans to write and read code. EDIT: That said, this is good news, in a sense.
You make me wonder which assembly you're talking about. x86-64 feels heavy with legacy designs, many ways to get the same result, common pitfalls regarding memory management, and some surprising very specific gems to make some things fast… such as SIMD. (I know little about other instruction sets.)
Earlier quoted context omitted.
I liked the "original" assembly more, at least it was designed for helping humans to write and read code. EDIT: That said, this is good news, in a sense.
You make me wonder which assembly you're talking about. x86-64 feels heavy with legacy designs, many ways to get the same result, common pitfalls regarding memory management, and some surprising very specific gems to make some things fast… such as SIMD. (I know little about other instruction sets.)
Maybe that's a good thing, at least then the goal is that people who care about performance don't write JS. But I'd prefer to just have the compile target as numbers then since you can't read the result anyway.
Earlier quoted context omitted.
Thanks for the link! I tried going through the issues (randomly clicking) but I am not seeing use cases. https://github.com/johnmccutchan/ecmascript_simd/issues/89 https://github.com/johnmccutchan/ecmascript_simd/issues/85 https://github.com/johnmccutchan/ecmascript_simd/issues/84 They are good technical discussions. What I am looking for is use cases for people to use in websites.
Vertex skinning [1] (code at [2]) is a classic example. (This code is not vectorized, but it could easily be and is usually vectorized via intrinsics in games.) Any 3D game that wants to animate human characters over a long period of time is likely to be using this technique. Since we want games to run on the Web, of course, this is a use case for Web sites. [1]: http://en.wikipedia.org/wiki/Skeletal_animation [2]: h…
Contrary to popular opinion, I think this is actually a terrible idea. By doing this, we are basically adding SIMD to the JS 'virtual machine'. IMO, we shouldn't standardize on API for things which are so low level and this is really like an implementation detail in the virtual machine. I would suggest two alternate approaches: 1. First come with a standard SIMD specification across CPUs. In some ways like the GL spe…
Oh. Dear. God. JavaScript is going to become the x86 of our time, i.e., the historically awful patchwork of kludges that gets passed onto each generation to kludge anew which also runs the entire world. JavaScript: we don't have integers, but, dammit, we have vector instructions. FML. Maybe it's not too late to take up painting.
I am so ungodly sick of Google pushing DART technologies everywhere. I really am starting to think their strategy is embrace, enhance, exterminate.
Contrary to popular opinion, I think this is actually a terrible idea. By doing this, we are basically adding SIMD to the JS 'virtual machine'. IMO, we shouldn't standardize on API for things which are so low level and this is really like an implementation detail in the virtual machine. I would suggest two alternate approaches: 1. First come with a standard SIMD specification across CPUs. In some ways like the GL spe…
Earlier quoted context omitted.
Autovectorization has been an area of intense compiler effort for a decade or more and by and large the primary customers of it (games, video codecs, etc.) prefer the intrinsics. It's perceived as too unreliable and brittle to be relied upon, and it's easy to see why: given a choice between having to think about what the compiler's alias analysis, overflow analysis, loop trip count analysis, etc. will do and just wri…
> video codecs, etc.) prefer the intrinsics. Prefer assembly. Intrinsics usually make a disaster of register allocation and you lose much of your performance to needless load/stores.
Lately I've been rather disappointed in how minimal the gains are in reducing register spills from intrinsics on modern CPUs, with their wide decode/issue, 16 registers, and dual load pipelines - by the time a loop is complex enough that a compiler spills, extra load/store uops are almost free from a micro benchmark perspective. The macro gains from smaller code and reduced cache usage are a bit bigger, but still depressingly minor for the effort expended.
But if you care about 32-bit x86 that's another story of course.
Contrary to popular opinion, I think this is actually a terrible idea. By doing this, we are basically adding SIMD to the JS 'virtual machine'. IMO, we shouldn't standardize on API for things which are so low level and this is really like an implementation detail in the virtual machine. I would suggest two alternate approaches: 1. First come with a standard SIMD specification across CPUs. In some ways like the GL spe…
>2. Identify proper use cases. SIMD is used a lot in all kinds of things dealing with video, so that's one area where it could find uses. I wouldn't mind being able to do (realtime) video processing in the browser. Some relevant reading that mentions SIMD.js briefly (though mostly that it wasn't really useful at all at the time of writing): http://tp7.pw/articles/javascript-video-filtering/
Oh. Dear. God. JavaScript is going to become the x86 of our time, i.e., the historically awful patchwork of kludges that gets passed onto each generation to kludge anew which also runs the entire world. JavaScript: we don't have integers, but, dammit, we have vector instructions. FML. Maybe it's not too late to take up painting.
>SIMD.js is originally derived from the Dart SIMD specification I am so ungodly sick of Google pushing DART technologies everywhere. I really am starting to think their strategy is embrace, enhance, exterminate.