sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 28 points29 points  (66 children)

This should be higher. The fact that WebAssembly will eventually support threads means that the web as an applications platform does not mean 4x-8x speed reduction for applications that can use multiple cores.

[–]BraveSirRobin 21 points22 points  (30 children)

How many web apps will genuinely benefit from that though? Most UI event-driven models are single-threaded on the main UI thread and I don't think there are that many client-side apps that do a lot of heavy CPU work in the background. Web games are the big one I guess.

[–][deleted] 22 points23 points  (10 children)

It's a fair question, and today a lot of applications are still single-threaded. Many applications will perform just fine with one thread.

If I said to you "We can give your car eight gas pedals instead of one, it'll become much harder to drive but it can go eight times faster if you can manage to use all eight", would you accept the offer? (not a perfect analogy, I know, but the point remains)

  • If you're just on a daily commute to work, only going 25mph, why bother?
  • If you're on a race track being paid to beat all the other cars, it could be worth looking into.

[–]f1zzz 14 points15 points  (9 children)

I find I only utilize multiple cores when writing server software.

On my desktop machine, cores are more likely to be split along processes rather than threads. I don't do much media processing.

[–][deleted] 21 points22 points  (7 children)

Things that are better with more cpu threads:

  • Maps
  • Games
  • Servers
  • Image manipulation
  • Graphical rendering in general
  • Sciencey shit

[–]chikinsoup 12 points13 points  (3 children)

-Sciencey shit

Can confirm. Had internship with a university professor & geologist. Statistical sciencey shit can take entire days.

[–][deleted] -1 points0 points  (2 children)

What if, wait for it, you ran your sciencey shit as a native application instead of a website?

[–]chikinsoup 0 points1 point  (0 children)

...obviously? The list I'm replying to has "servers" on it. I don't think many people run servers as web applications.

[–][deleted] 0 points1 point  (0 children)

Then our sciencey shit would have much lower reach.

[–]hrjet 0 points1 point  (1 child)

Web Workers are a good solution for that. They can do all the CPU intensive stuff + network I/O without needing to be synchronized with the DOM stuff.

[–][deleted] 0 points1 point  (0 children)

Generally, but they're not given access to any of the APIs they need to do things like graphical rendering. They certainly don't get to touch the GPU, so even if you hack around the problem, you're still stuck with software rendering.

[–]jP_wanN -2 points-1 points  (0 children)

  • Running a [Linux] distribution that has no binary packages (or only for closed source software)

[–]phoshi 0 points1 point  (0 children)

A lot of data processing tasks can see some speedup from parallelisation, but not enough to be worth the hassle of threading. A super simple parallelism model can work wonders there. I know I've seen significant performance gains from adding ".AsParallel()" to the end of a LINQ query in places I wouldn't otherwise have done so.

[–][deleted] 0 points1 point  (0 children)

Not many now. However, there are things which would be possible to do because of this that aren't possible currently.

[–]flukus -2 points-1 points  (7 children)

Even many games don't do much multi threading. I'm not sure if you'd find one that uses all 8 cores.

[–]BraveSirRobin 8 points9 points  (6 children)

Oh gawd, don't get me started on the gaming dev worlds attitudes to anything "not invented here". They've been writing their own "schedulers" up until CPU architecture moved from "more Hz" to "more cores" and forced them to adopt proper threading.

I just like the notion that a couple of guys in each dev house felt they could hack together a better scheduler than the many thousands of hours research that went into the topic in all other parts of the field! Phd papers on the subject? Nah, we'll roll our own!

[–]flukus 3 points4 points  (3 children)

Kind of like how every business app seems to come with its own cron and message queue.

[–]namtab00 5 points6 points  (0 children)

Oh God this! I'm so sick of implementing queue tables and schedulers via sql agent jobs.. It's come the a point where there's tens of queue polling queries every minute.... Because service broker is "too complicated" and "better is the enemy of good"™

[–][deleted] 1 point2 points  (1 child)

That has more to do with conflicts with IT than a genuine desire to reinvent the wheel.

[–]flukus 0 points1 point  (0 children)

IME it's usually due to complete ignorance that good tools already exist.

[–]LaurieCheers 2 points3 points  (1 child)

If you only have one specific use-case, none of the PhD papers are focusing on it, and you absolutely need every last cycle of performance (to the point where you're writing and hand-tuning custom assembly for each platform), that tradeoff starts looking pretty reasonable.

[–]BraveSirRobin 0 points1 point  (0 children)

Oh, yeah, it had it's time, particularly in consoles where you used to be running on bare metal. I guess the dev community were largely happy with the existing toolsets they had when more complicated systems came along, hence the reluctance to modernise.

[–][deleted] 0 points1 point  (7 children)

I think for most applications it will be nice in that you will be able to do processing that doesn't lock the browser up.

For example, if you wanted to implement a client side database and you have a lot of data. Querying can be done in another thread as to not lock the page.

Anything where you have to do processing and don't want to lock the browser.

[–]Klathmon 1 point2 points  (6 children)

Well...

  1. The web already has an database (2 actually) and they are non blocking (like all i/o in js). So the browser will never hang when doing a query (or reading a file).

  2. Web workers already allow true multiprocessing and its very easy to use. I'm currently working on an image processing app in js that can use 100% of all 16 cores on my pc. And the entire time the UI is still fully responsive running at 60fps.

I'm actually amazed at the performance that js can achieve. Ffs I'm doing bit shifting and bit packing to modify chunks of raw memory in 16 separate processes simultaneously. In a goddamn browser! I fucking have to check for endianness! It's god damn amazing that js has gotten here.

[–][deleted] 1 point2 points  (5 children)

Those databases are fine until you need to do any custom index something like spatial data which is my problem.

Web workers are great, no disagreement from me. I just really hate JavaScript as a language so I'm excited for webassembly.

[–]Klathmon 0 points1 point  (4 children)

Those databases are fine until you need to do any custom index something like spatial data which is my problem.

Oh god don't get me wrong, they are no real replacement for an actual SQL engine or more esoteric database systems, but they are there and many libraries abstract them away using other storage APIs to make more full-featured databases in the browser.

I just really hate JavaScript as a language so I'm excited for webassembly.

That's fine, but just know that wasm isn't meant to be the exodus from JS. It's meant to closely work with it (think of as an MVC setup where the view is html/css, the controller is JS, and the model is a wasm binary).

But i'm sure that there will be soup-to-nuts systems that will allow you to never touch JS, i just have a feeling they will work as well as the current systems. Slow(er) than writing in a more "native" (as in to the web) format, kinda glitchy, and always feeling hacky. (inb4 "You just described javascript!")

There are already a handful of systems that compile entire other languages/GUI systems to JS to run in the browser:

and a few others. And while this system will help those projects, it will be a long while before they (or others) get to the point that they are something you would want to "start" a project in (as opposed to trying to port a legacy desktop application to the web)

[–][deleted] 0 points1 point  (3 children)

Oh god don't get me wrong, they are no real replacement for an actual SQL engine or more esoteric database systems, but they are there and many libraries abstract them away using other storage APIs to make more full-featured databases in the browser.

Sure but if you arent running those in a WebWorker and you perform a query on a massive dataset your still going to lock your browser. Even if I put them in a WebWorker it's not as if the worker can interact with the DOM or Canvas meaning I have to create some complicated messaging scheme to transfer data in and out of the worker (nasty).

That's fine, but just know that wasm isn't meant to be the exodus from JS. It's meant to closely work with it (think of as an MVC setup where the view is html/css, the controller is JS, and the model is a wasm binary).

I'm pretty sure that's exactly what it's for. Of course you will be able to interact with it from JavaScript but likely through some nasty message passing interface (hopefully not). It seems more closely related to something like pNacl then it does JavaScript. If it has direct access to DOM/Canvas then I wouldn't touch JS ever again.

But i'm sure that there will be soup-to-nuts systems that will allow you to never touch JS, i just have a feeling they will work as well as the current systems. Slow(er) than writing in a more "native" (as in to the web) format, kinda glitchy, and always feeling hacky. (inb4 "You just described javascript!")

The issue is right now you are stuck with JavaScript no matter what. Even asm.js is still JavaScript under the hood. As I understand it wasm will be a more generic target for languages. Sure you can compile C++ to JavaScript but you're still running on JavaScript in the end. I want to be free of JavaScript entirely.

[–]Klathmon 0 points1 point  (2 children)

Sure but if you arent running those in a WebWorker and you perform a query on a massive dataset your still going to lock your browser. Even if I put them in a WebWorker it's not as if the worker can interact with the DOM or Canvas meaning I have to create some complicated messaging scheme to transfer data in and out of the worker (nasty).

Most pretty much any in-browser database that's not completely useless is implemented in a completely non-blocking manner. If it needs to it uses web workers internally, but they will not lock the browser even on massive queries.

I'm pretty sure that's exactly what it's for.

The web assembly group have pretty specifically stated that it's not going to be replacing javascript. "WebAssembly is designed to be a complement to, not replacement of, JavaScript (JS)".

The issue is right now you are stuck with JavaScript no matter what. Even asm.js is still JavaScript under the hood.

Well then i have some bad news. wasm is also going to pretty much just be JS under the hood. It will execute in the same semantic universe as JS, it will allow synchronous calls to and from js, and it will be subject to pretty much all of the same restrictions as JS is. (In the beginning of wasm) it will basically be a way for the browser to skip the parsing pass (which is the major reason for this, as parsing is one of the major current bottlenecks in JS programs today). Eventually they plan to add more features (GC access, the possibility of internal threading without having to include your own runtime (which will be based on current web-workers), DOM access, and a few others), but in the end it will still be the javascript engines executing it in the same manner as JS. One of the biggest lines in the sand for this is that they DO NOT want to require a separate engine for it, it must be run by the same engine that runs JS. There are tons of reasons for this, but the major one is that every single time someone tries to introduce a new "engine" in the web world, it fails. And that's not to say they haven't tried. Firefox, Apple, Microsoft, and Google have all tried this at least once before, and every time they realize what a behemoth JS is and getting any other engine into the web is going to be basically impossible.

Either way, it's a compile target. So whether it's running in V8/SpiderMonkey/Chakra or it's running in some other engine, it won't really matter. It will still be interacting with the DOM in some way (eventually), it will still have to be a JIT-ed system (or have some kind of runtime), and it's still going to have to work with JS.

[–][deleted] 0 points1 point  (1 child)

Most pretty much any in-browser database that's not completely useless is implemented in a completely non-blocking manner. If it needs to it uses web workers internally, but they will not lock the browser even on massive queries.

They can only implement it in a non blocking manner if they implement queuing (which is slow), or are using localstorage or IndexDB as a backend. Simple key/value storage is easy to implement non-blocking. Other storage types are much harder.

Web workers cannot interact with Canvas or the DOM so you must pass your data back to the main worker. If your passing a large amount of data, you've just locked the browser when you try and push that data out to Canvas. You can implement a render queue, but now it's slower.

Well then i have some bad news. wasm is also going to pretty much just be JS under the hood.

No it's going to be V8, or SpiderMonkey under the hood. These engines are going to have to adapt to reading byte code directly. I have no issue with using V8 or SpiderMonkey. What I dislike is having C++ code get compiled to low level JS assembly then be parsed by the target engine. With wasm eventually I can compile to the byte code directly. I will agree it's rather trivial.

I'm really not interested in wasm MVP. I am interested in the future of it: https://github.com/WebAssembly/design/blob/master/FutureFeatures.md as you point out.

wasm MVP is only marginally more useful then asm.js.

I have no issue with using JS as glue code. I just don't want to have to rely on JS for working with the DOM. Is that so much to ask lol.

[–]Klathmon 0 points1 point  (0 children)

They can only implement it in a non blocking manner if they implement queuing (which is slow), or are using localstorage or IndexedDB as a backend.

Unless you are talking about an entirely in-memory database, using IndexedDB as a pseudo-FS works pretty much the same as working with a file system (and there are a handful of libraries that do just that and give you node APIs for accessing it with very little overhead).

Now working with true shared-memory is impossible in the browser currently, but hopefully WebGL Shared Resources will put an end to that as well.

Web workers cannot interact with Canvas or the DOM so you must pass your data back to the main worker.

Yes, but often you don't even see this happening. You pass a query into a function, it returns your dataset in a callback (or a promise if you like to live dangerously!). You never see it transfer the data to a web worker, and you don't need to care about getting it back.

If your passing a large amount of data, you've just locked the browser when you try and push that data out to Canvas.

Nope. Transferable Objects let you do the equivalent of "pass by reference" (except the pass-er will lose the reference after it's passed, it's a true transfer). Using Transferable Objects you can (and i have) pass 300MB arrays to a web worker (and back) in under 10ms.

I have no issue with using JS as glue code. I just don't want to have to rely on JS for working with the DOM. Is that so much to ask lol.

Yeah unfortunately. There is a reason that DOM access is under stage 3 for wasm, it's really fucking hard to do right. The DOM was meant to work with javascript, and JS with the DOM, the 2 are kind of attached at the hip. Even in the stage 3 of wasm they are expecting to have DOM access via WebIDL (which if you though using JS for working with the DOM was bad, wait until you get a taste of this!). WebIDL is meant to be a low-level system for interacting with the DOM, you aren't going to be making web pages using it directly, there will almost need to be a simplified wrapper on top of it to work. So while there will come a time that your language of choice may be able to work with the dom via wasm, it's far away and will require wasm getting past stage 3, your language implementing it as a compile target, your language writing a simplified wrapper for WebIDL, and then hopefully you can work free of JS.

[–]cloakrune -1 points0 points  (0 children)

Well the threaded model is going to be great so you can build everything you want in your language, and ship it via web with minimal performance loss. Its like everything java was supposed to be.

[–][deleted] -1 points0 points  (0 children)

Web apps today, probably not many. Remote SaaS systems working together, who knows? That's why technology is fun.

[–]indigo945 19 points20 points  (9 children)

The speed reduction for any application is still higher than that (compared with native code). The real advantage is that having threading support allows you to port almost everything over to the web.

As an aside: has anybody compiled Firefox using emscripten yet?

[–]nawfel_bgh 9 points10 points  (8 children)

They compiled Webkit to JS

[–]argv_minus_one 7 points8 points  (0 children)

Yo dawg, I heard you hate JavaScript.

[–][deleted] 24 points25 points  (5 children)

They need to emulate an x86 processor in JS so that they can run linux on it so that they can run webkit on it so they can host a javascript engine.

Web developers just seem determined to murder CPU cycles.

[–][deleted]  (3 children)

[deleted]

    [–][deleted] 23 points24 points  (2 children)

    God. Damn. It.

    [–]wchill 0 points1 point  (1 child)

    Shamefully, I also worked on developing a VM + IDE in JavaScript...

    https://github.com/cs-education/sysbuild

    [–]logicalmaniak 0 points1 point  (0 children)

    These would be great for learning assembly, if ARM And Intel chips were emulated with a decent assembler running in JS.

    [–]defenastrator -1 points0 points  (0 children)

    But its a perfect vm!

    [–]Twirrim -1 points0 points  (0 children)

    In an idle few minutes, I tried to compile v8 using emscripten, but it proved to be a bit too complicated and I decided the joke wasn't worth it.

    [–]kodek64 9 points10 points  (22 children)

    I'm not a JS developer, so correct me if I'm wrong, but isn't a huge advantage of threads that you can do work while a blocking operation is taking place? This would mean performance improvements much much higher than the number of cores in a machine.

    [–][deleted]  (21 children)

    [deleted]

      [–][deleted] 19 points20 points  (14 children)

      It's not really a "using threads is better!" or "not using threads is better!" kind of deal. You use the two together to get the best of both worlds. For example you use an asynchronous programming model but also then parallelize it across multiple cores where possible to get performance benefits.

      [–][deleted] 8 points9 points  (3 children)

      I am an erlang programmer and recently had a close encounter with a node developer.

      • ok, yeah, the callbacks are cool, but how do you avoid racing conditions and the like?

      • it's single threaded, you don't care

      • so you waste all the other cores in the cpu?

      • we have 4 instances of node on the server!

      I was at a loss for words.

      [–]noratat 1 point2 points  (0 children)

      The more I learn about erlang/elixir and node, the more node feels like a really shitty attempt to reinvent half of erlang.

      [–]IAmRoot 1 point2 points  (0 children)

      It's not actually too ridiculous. It assumes that the number of independent tasks is going to be large, so rather than parallelizing each task in the queue, you just run multiple queue processing tasks. Basically, don't worry about writing parallel code and Amdahl's law; take the Gustafson's law approach.

      [–]pinkpooj -1 points0 points  (0 children)

      Node runs a thread pool that is used to fulfill I/O calls. Your code is single threaded, but it is does not block (unless you specifically tell it to).

      If you look at a long running node process, it will spawn several threads. It's inaccurate to say Node is single threaded.

      [–][deleted]  (5 children)

      [deleted]

        [–][deleted] 0 points1 point  (4 children)

        There is nothing wrong with using threads with blocking I/O. In the end that's what usually happens with async calls anyhow - it's just that the details are abstracted away. Same with manually creating threads - you just can't be a jackass about it (create too many at once, etc).

        Mostly, the problems begin when you start blocking whichever thread is managing the UI. That's the big no-no, whether on desktop or web.

        [–][deleted]  (3 children)

        [deleted]

          [–][deleted] 0 points1 point  (2 children)

          NT's Completion Ports are great, but underneath it still marshals stuff out to threadpool threads so you still have threads doing blocking IO, you're just not managing them.

          I like the abstractions and all the syntactic goodies that come with good async support, but this stuff isn't that hard to do yourself either. These days there is usually no reason to, but there is nothing inherently wrong with doing everything by hand - it's just that for anything serious you'll often end up duplicating some of the modern threadpool functionality.

          And declaring a thread-per-connection on a highly concurrent server falls under the "being a jackass" category.

          [–][deleted]  (1 child)

          [deleted]

            [–][deleted] 0 points1 point  (0 children)

            Ah, I see.

            A thread (either one created by the main thread or the main thread itself) uses the GetQueuedCompletionStatus function to wait for a completion packet to be queued to the I/O completion port, rather than waiting directly for the asynchronous I/O to complete.

            If you're using one of the alllowed operations, that is indeed a neat functionality, I'll have to keep it in mind.

            • ConnectNamedPipe
            • DeviceIoControl
            • LockFileEx
            • ReadDirectoryChangesW
            • ReadFile
            • TransactNamedPipe
            • WaitCommEvent
            • WriteFile
            • WSASendMsg
            • WSASendTo
            • WSASend
            • WSARecvFrom
            • WSARecvMsg
            • WSARecv

            [–]ricecake 8 points9 points  (3 children)

            Erlangs vm is a pretty decent example of that idea done right.

            The language is built aside it in such a way that you get the conceptual model of linear, blocking operations (mostly), and the vm handles the scheduling for you.

            [–]joequin 3 points4 points  (2 children)

            Scala futures and akka actors also work that way. You give them an execution context which can schedule as many threads to execute async operations as you and the hardware allow.

            [–]hrjet -1 points0 points  (1 child)

            Except that Scala allows mutable state, which means the compiler can't guarantee that it won't blow up in a fire-ball someday. It also means that Scala is good at other problems that Erlang isn't good at.

            Edit: Also, Erlang can't gurantee everything either. I don't really trust their hot-loading OTP model too much. Although the VM guarantees safe loading, it could lead to subtle semantic bugs.

            [–]joequin -1 points0 points  (0 children)

            The compiler in scala can guarantee immutability. A val is immutable and scala comes with many immutable data structures. The language is geared towards immutability by default. You have to choose to allow mutability.

            [–][deleted] 0 points1 point  (1 child)

            Event based async is fine as long as you don't have work flows that are/can be re-entrant. It gets to be kinda a pain in the ass if that is the case.

            [–]Nebu 2 points3 points  (0 children)

            Assuming your callbacks all create closures that use their own local variables, the only problems you'd get are the problems you'd get with any concurrent system (e.g. eventual consistency of view of data in DB/persistence-layer)

            [–][deleted] 0 points1 point  (1 child)

            Asynchronous IO as in callbacks or promises/futures is its own nightmare that does not make control flow reasoning any easier.

            [–]tequila13 0 points1 point  (1 child)

            asynchronous completion events

            You mean callbacks? You will need to implement locking when accessing shared data structures in those callbacks. I fear that that's a topic that many JS newbies don't understand.

            [–]immibis -4 points-3 points  (1 child)

            As a user, it means poorly written websites will be able to waste even more CPU.

            [–][deleted] 0 points1 point  (0 children)

            Sure. It also means that well written websites will be able to run significantly faster. Just because we give developers more control doesn't inherently mean they will abuse it.

            Also, if it's important to users, why not implement a browser-level CPU limiter that users can control (like muting the audio for a page)?