Intel brings SIMD to JavaScript

[nburns]

I saw this link on Hacker News. SIMD support may make it possible to write sophisticated compression algorithms that run in a web browser and are fast. The browser isn't exactly the easiest platform to develop for, but being able to run code in a browser is pretty nice -- you can't argue with that.

Aside from compression demos and situations where compression is the goal, perhaps compression implemented in javascript could be used behind the scenes to more efficiently transmit and store data from the web.

It occurred to me separately that websites with multiple different pages typically have a lot of redundant elements on every page. If you could take advantage of this redundancy in an orthogonal way on the client and/or server, you could potentially save a lot of data.

Direct link:
https://01.org/blogs/tlcounts/2014/b...imd-javascript

Hacker News thread:
https://news.ycombinator.com/item?id=7877147

[just a worm]

This is just stupid. Really.

The SIMD instructions which are offered by Intel for the x86 architecture are already made for pretty sophisticated situations. There are a lot of general purpose instructions missing. Like multiple accesses to the memory. That's why the SIMD instructions can't be used often enough even if you have the full capabilities which the machine language offers.

If you can use SIMD instructions because the instructions fit your purpose, then the overall speed gain is usually below 10%. If it's higher then you might have a situation which is exactly what thouse instructions are made for or you are comparing the speed up with a bad written code. There are ways to reach SIMD a-like speeds with the general purpose instruction set.

SIMD can't be integrated easily into a programming language nor a script language. Normaly you need to manually select a few instructions which fulfill your purpose and you end up with an individual stream of instructions which solve your problem. What a compiler or an interpreter outputs is more something like a patch-work of short code pieces. And all thouse pieces normaly don't contain anything which can be optimized with the existing SIMD instruction set. Maybe a run through an array to find an integer value or something like this. But you wouldn't have this situation often. So the overall speed gain is nearly not worth mentioning. But the compatibility draw back is worth mentioning.

With or without SIMD: Using java script to do real processing is a waste of energy. It mainly shows that the person who wrote it has no clue of real programming.

[Piotr Tarsa]

Well, those SIMD extensions can bring speed up only if you actually make an algo that's much faster with SIMD than without. I've once developed JavaScript version of TarsaLZP: https://github.com/tarsa/TarsaLZP It wasn't super-slow actually, but nonetheless JavaScript is a PITA when it comes to integer operations.

I don't see SIMD JavaScript as a potential game-changer. WebCL was supposed to accelerate in-browser computations but support for it is (almost?) nonexistent. Other than that, JavaScript will remain a power hog - JavaScript heavy websites tend to lag severely and consume a lot of CPU power.

[nburns]

JavaScript doesn't have a lot to recommend it -- except for allowing pretty much anyone in the world to run your code without installing it. Actually, that is a lot

[Piotr Tarsa]

Installing? I thought one can write software that doesn't need installing to be able to run.

Also, there's JNLP: http://en.wikipedia.org/wiki/Java_Web_Start where you only need to download a small XML-based file and Java runtime takes care of downloading code and updating it whenever necessary.

[nburns]

Installing? I thought one can write software that doesn't need installing to be able to run.

Also, there's JNLP: http://en.wikipedia.org/wiki/Java_Web_Start where you only need to download a small XML-based file and Java runtime takes care of downloading code and updating it whenever necessary.

It's much less convenient. Example: you run javascript code every time you visit a website, without even intending to. If every web page was a Java Web Start application, would anyone bother browsing the web? Also, people have an incentive to keep their browser reasonably updated, just so web pages look decent. If you write a Java application, most people will probably have to install some kind of VM before they can use it.

I'm not sure what Java_Web_Start does, but, generally, I consider java applications unnecessarily difficult to run. I really dislike classpaths.

[just a worm]

JavaScript ... allowing pretty much anyone in the world to run your code without installing it.

Java script needs an interpreter. Normal programms need a loader. The loader is part of the operating system so you have it on your computer as soon as the operating system is installed. A java script interpreter is normaly not a part of the operating system. Windows comes with a java script interpreter. But they had legal problems in the past because they integrated the windows explorer and the internet explorer in the graphical user interface of the operating system.

To put it all together: Normaly you also need to install a java script interpreter first befor you can run a java script. You can't run java or the framework stuff either. But if you have installed all the stuff that you need then usualy the files run and everything is done in the background for you.

How can the SIMD instruction set help when it's about interpreting java script?

[Piotr Tarsa]

JavaScript is JITed in modern browsers, just like Java bytecode under JVM. That means the code is profiled at runtime and hottest parts are compiled on the fly to native code.

But the overly (IMO) dynamic nature of JavaScript means you need to deal with lots of bookkeeping data and extra checks, which makes optimizations harder and increases the memory usage. That's why browsers tend to use hundreds of megabytes of memory after even a short usage and pages lag severely when they are loaded with lots of JavaScript.

[nburns]

JavaScript is JITed in modern browsers, just like Java bytecode under JVM. That means the code is profiled at runtime and hottest parts are compiled on the fly to native code.

But the overly (IMO) dynamic nature of JavaScript means you need to deal with lots of bookkeeping data and extra checks, which makes optimizations harder and increases the memory usage. That's why browsers tend to use hundreds of megabytes of memory after even a short usage and pages lag severely when they are loaded with lots of JavaScript.

JavaScript will never be as fast as C++, but it's one of the fastest interpreted languages now, thanks to all the work that went into the VMs, like v8. How sure are you that the lag is caused by JavaScript?

[Piotr Tarsa]

Because sites light on JavaScript operate smoothly while ones with lots of JavaScript and lots of content (and I don't mean any Flash animations etc) are often laggy.
Probably the lag isn't caused solely by JavaScript, but usually the situation is that sites with lots of JavaScript have pretty complex DOMs.

[nburns]

Because sites light on JavaScript operate smoothly while ones with lots of JavaScript and lots of content (and I don't mean any Flash animations etc) are often laggy.
Probably the lag isn't caused solely by JavaScript, but usually the situation is that sites with lots of JavaScript have pretty complex DOMs.

JavaScript can, of course, be a source of performance problems. A pathologically-complex DOM could probably contribute. Web performance is a complex subject, because there are many players involved. This site can be slow. If the slowness is happening on the client side, i.e. the browser, there are things you can do, like make sure you're running an up-to-date browser. I swore by Firefox for years, but I noticed that people drifted over to Chrome, so I switched. Firefox is a monolithic process with threads, while Chrome isolates pages in separate processes (back when Mozilla adopted a multithreaded architecture, I thought it was a mistake). Firefox has issues with locking and contention and a thread can hang and bring down the entire browser. Some of that stuff probably just needs a rewrite, applying lessons learned, and that's basically what Google did when they created Chrome. Of course, then there are server-side issues, and there's not much you can do about that.

There are browser add-ons for profiling websites and finding out what's going on. If you're interested, checkout Firebug on Firefox, or whatever you can find for the browser you use.

[lunaris]

The javascript hype. In the past ,javascript have only a purpose to be a tool for html.

Because of the fast grow of business on online services,W3C and all devs gets crazy trying to do javascript a general purpose language,instead a tool for html.This is very stupid.It's just because money and business.

[nburns]

The javascript hype. In the past ,javascript have only a purpose to be a tool for html.

Because of the fast grow of business on online services,W3C and all devs gets crazy trying to do javascript a general purpose language,instead a tool for html.This is very stupid.It's just because money and business.

You don't have to buy into any hype. If you want to write code that runs in a browser, it's pretty much javascript or nothing.

[Piotr Tarsa]

Minor correction: If you want to write code that runs in a browser without plugins, it's pretty much javascript or nothing.
Java is installed on many desktop computers. But not on tablets or smartphones.

[lunaris]

You don't have to buy into any hype. If you want to write code that runs in a browser, it's pretty much javascript or nothing.

I know,but I was trying to say is w3c and all business is trying to make everyone uses javascript for all types of things (even a 3d engine).W3c and business is trying to convince you write all your apps in javascript (webapps) than other client languages .


Javascript should be limited to be a tool for HTML.Not a super framework to write all types of apps.

[Matt Mahoney]

Javascript also works without the hassle of Java long load times and making me click through warnings about unsigned applets and out of date software. Java was a good idea until Oracle bought Sun and started suing everyone that tried to make it easy to use.

[nburns]

I don't think oracle had much to do with it. JavaScript's success was partly an accident. But it helped that it was designed from the start to run in browsers.

[m^2]

Javascript also works without the hassle of Java long load times and making me click through warnings about unsigned applets and out of date software. Java was a good idea until Oracle bought Sun and started suing everyone that tried to make it easy to use.

IMHO Java in a browser never was a good idea.
I'd rather avoid having a turing-complete technology for simple information relaying like what happens on the web at all. But that's not practical nowadays.

[Piotr Tarsa]

Adobe Flash was very popular for a long time, so Java had potential as it had similar advantages and disadvantages. I think the main reason Java didn't gain traction in browsers was lack of modularization - Java Runtime was large, requiring long startup times, hogging memory and causing lots of swapping. There was no way of telling the loader to only load a portion of runtime. That's changing only in Java 8 AFAIR, so it's certainly too late to dominate dynamic web content now.

[just a worm]

How sure are you that the lag is caused by JavaScript?

I can confirm that javascript causes serious lags when browsing the internet. On quite some sites Firefox nearly completly hangs (no reaction of the user interface) for half a minute or so or even longer. If I deactivate javascript then the page loads within less than a second.

Actually there is an option to limit the script execution time but this function doesn't work reliable.

Bad implementations like thouse from Mozilla discredit the whole script language and make it appear slower than it should be.

[nburns]

I can confirm that javascript causes serious lags when browsing the internet. On quite some sites Firefox nearly completly hangs (no reaction of the user interface) for half a minute or so or even longer. If I deactivate javascript then the page loads within less than a second.

Actually there is an option to limit the script execution time but this function doesn't work reliable.

Bad implementations like thouse from Mozilla discredit the whole script language and make it appear slower than it should be.

When you disable javascript, you will break a large amount of functionality. So it's not only script execution time that you are measuring.

[lunaris]

I can confirm that javascript causes serious lags when browsing the internet. On quite some sites Firefox nearly completly hangs (no reaction of the user interface) for half a minute or so or even longer. If I deactivate javascript then the page loads within less than a second.

Actually there is an option to limit the script execution time but this function doesn't work reliable.

Bad implementations like thouse from Mozilla discredit the whole script language and make it appear slower than it should be.

The problem is not mozilla javascript engine.Mozilla engine is better than lots of scripts engines. Flash sometimes is much worse.It entirely lags all the system.Because flash is another "script language" used to things like movie processing and games.

The problem is the use of a script language to do complex tasks(like very complicated movie processing and 3d engines).Script languages are not made to do these tasks.But W3C and business interests force the use of javascript for complex things like advanced compression,vectorization,3d engines.


W3C is corrupted by business because online services generates lots of money.

[nburns]

The W3C may be corrupt, but I don't think they have an interest in pushing JavaScript. JavaScript was created by Netscape in the 1990s. It became the standard browser language largely by default, because it was supported by all browsers (unlike VBScript), it didn't need a plugin (unlike Java and Flash), and no company controlled it. AFAIK Google was largely responsible for making it what it is today. They seized on it to create Google Maps, which showed everyone its potential, and they pushed it by developing a high-performance VM (v8 for Chrome) and by using it extensively (Google docs, Gmail).

If there is a conspiracy to push JavaScript, I'd suspect Google.

[lunaris]

The W3C may be corrupt, but I don't think they have an interest in pushing JavaScript. JavaScript was created by Netscape in the 1990s. It became the standard browser language largely by default, because it was supported by all browsers (unlike VBScript), it didn't need a plugin (unlike Java and Flash), and no company controlled it. AFAIK Google was largely responsible for making it what it is today. They seized on it to create Google Maps, which showed everyone its potential, and they pushed it by developing a high-performance VM (v8 for Chrome) and by using it extensively (Google docs, Gmail).

If there is a conspiracy to push JavaScript, I'd suspect Google.

It's not only google.All advertising companies (and evil MPAA trying to push EME) are trying to make user to use all apps only in browser instead using your apps installed on computer .I'm still using Mozilla client mail (Thunderbird) but most of people today use webmail services like gmail.

Chrome V8 costs a lot of money and development.V8 is a google illusion trying to force people write apps using javascript.But chrome v8 still slower than C,Java and .NET.

All html5 hype have business interests on javascript too.

[nburns]

Chrome V8 costs a lot of money and development.V8 is a google illusion trying to force people write apps using javascript.But chrome v8 still slower than C,Java and .NET.

Whether javascript is slower or faster depends on how you're using it. Java apps can be heavy and slow to start, which I think may be a consequence of the Java philosophy of implementing every part of the Java API in Java. Javascript has basic data structures and algorithms built right into the language, and they can be implemented using native code in the VM wherever it makes sense.

[Piotr Tarsa]

I would say standard Java implementation uses more native functions than the total number of function the JavaScript exposes. It's just that the size of core library in Java is huge compared to those of JavaScript. Add to that the fact that JRE parses and verifies the entire bytecode from JRE on each JVM process startup. That's kind of sick and that's because of lack of modularization, but modularization is in the works (so it will be there someday). Implementing big chunk of Java runtime in Java itself has the advantage that Java can be progressed by simply including more and more well known and reliable libraries into the standard runtime, among other advantages like flexibility, reduced number of bugs, etc.

JavaScript has relatively small core API so JavaScript VM starts fast but OTOH you still need bulky libraries to become productive, so developers are using heavy JavaScript frameworks which add to download size and memory footprint of application. So it becomes close to Java with its disadvantages, just that JavaScript scales down better than Java.
JavaScript is good (fast and light) when your site is not very dynamic. Sites that are very dynamic and use JavaScript extensively tend to hog memory and CPU even stronger than Java apps.

[nburns]

JavaScript is good (fast and light) when your site is not very dynamic. Sites that are very dynamic and use JavaScript extensively tend to hog memory and CPU even stronger than Java apps.

There's no way to implement those sites using anthing but Javascript, really, so I don't know how you could support a claim that some other language would work better on those sites. Javascript is as much built in to the web as CSS.

For every kind of problem, there is a matching solution, and for every solution, i.e. programming language, there is a problem or problems that match that language. At least, you'd hope so, or else it's worthless. The problem Java was designed for is nothing like the problem that web browsers currently have, and it's exactly the problem that Javascript was designed specifically for and has always been its primary purpose. In all the ways Java differs from Javascript, I don't see any that would actually give Java any advantage in the browser, but many would make it worse.

[Piotr Tarsa]

So what's the problem JavaScript was designed to solve and which other languages can't solve?

I remember sites built entirely in Adobe Flash not that long ago.

[Matt Mahoney]

x86 emulator running Linux written in Javascript. http://bellard.org/jslinux/index.html

[lunaris]

Javascript is slow because the data types are not good for vectorization

Javascript is entirely dynamic.Does not use static compilation or bytecode compilation.All must be executed "live".
Javascript initial purpose is only to help html be better .And not to be a framework for complex applications like stupid javascript 3d engines.


Script languages are not system languages or application programming languages.Script languages are to help another languages.It's stupid make a 3d engine or hd movie processing entirely on javascript/html5/flash.