Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Concurrent JavaScript: It can work

webkit.org

Post reply on HN
Print view View original

171–180 of 189 posts

Re: Concurrent JavaScript: It can work

#171

Post by Jtsummers »

pizlonator wrote: post #169
coldtea wrote: post #81

Earlier quoted context omitted.

When told that multi-threaded access is hard and messy, "X program uses threads and it's not a mess" is not an argument -- for one because nobody said X program is a mess. Threads being messy is not a transitive property. Nobody doing threads ever said that they are not messy or that multi-thread access and locking et al are easy.

You just called WebKit a twisted mess. I asked you for examples. Looks like you don’t have any. Like I said, WebKit uses threads and it’s great. Maybe some day you will also learn to use threads.

coldtea literally never said that WebKit was a twisted mess.

robertwhiuk, responding to you, referenced using "twisted mess"

pizlonator:

  I think it would be weird if objects were thread-
  restricted by default. Concurrency is most fun when it's
  easy for a thread to access an object it wants.
robertwhiuk:

  You say fun, but what you mean is twisted mess.
No reference yet to WebKit until your response:

  WebKit uses threads. WebKit is not a twisted mess.
coldtea chimed in with this:

  WebKit needs tons of extra effort to keep it from being a
  twisted mess precisely because it uses threads.
What is that "extra effort"? Discipline, care, good work. coldtea does not call WebKit a twisted mess. In fact, they seem to be saying the opposite. That it is not a twisted mess despite using threads.

You have some good points in this discussion, generally. But you should at least be honest in your characterization of other people's comments.

  Maybe some day you will also learn to use threads.
Maybe someday you will also learn reading comprehension.

Re: Concurrent JavaScript: It can work

#172

Post by pizlonator »

blub wrote: post #157
pizlonator wrote: post #146

Earlier quoted context omitted.

Tests are great. No harm in tests. I just don't think that we have sufficient evidence to conclude that using type systems to aid the development of concurrent code actually leads to better concurrent code. Therefore, I err on the side of not using the type system for that purpose so that I can use it for many other things that I think it's really good at. (Just take a look at JSC's source code if you want to see our…

Any specific parts of JSC one should look into? Btw, in case others are also wondering: JSC is JavaScriptCore.

All over.

We use smart pointers over raw pointers.

We have probably hundreds of data types defined as classes, which have only very controlled conversions to other data types. See things like DFG::AbstractHeap or B3::ValueRep.

Re: Concurrent JavaScript: It can work

#173

Post by pizlonator »

Jtsummers wrote: post #171
pizlonator wrote: post #169

Earlier quoted context omitted.

You just called WebKit a twisted mess. I asked you for examples. Looks like you don’t have any. Like I said, WebKit uses threads and it’s great. Maybe some day you will also learn to use threads.

coldtea literally never said that WebKit was a twisted mess. robertwhiuk, responding to you, referenced using "twisted mess" pizlonator: I think it would be weird if objects were thread- restricted by default. Concurrency is most fun when it's easy for a thread to access an object it wants. robertwhiuk: You say fun, but what you mean is twisted mess. No reference yet to WebKit until your response: WebKit uses threads…

coldtea was unable to come up with a single example of where WebKit is a twisted mess or even needs effort to avoid becoming one. No matter what kinds of semantics you throw at this, I think it’s the case that these arguments against threads lack basis.

Re: Concurrent JavaScript: It can work

#174

Post by pizlonator »

coldtea wrote: post #164
dboreham wrote: post #118

Earlier quoted context omitted.

Oh ffs I feel like I'm back in 1994 or so...

Because there was some huge breakthrough since eliminating threading issues? (If you answer just use Erlang, CSP or any other variation, well, my point exactly).

The only breakthrough is that some of us learned to use threads. Apparently some of us didn’t.

Re: Concurrent JavaScript: It can work

#175

Post by first_amendment »

pizlonator wrote: post #166
first_amendment wrote: post #155

Earlier quoted context omitted.

This isn't about "paternalistic caution," it's about purposeful and sensible engineering. JavaScript wasn't designed for threading, and it's a less natural fit for it compared to a language like C, so this is understandably a pretty serious undertaking. Your point is that this may enable some currently unimplementable application in JavaScript. The assumption is that Firefox couldn't have existed without a free-for-a…

Imagine having an app that wants to perform a concurrent search on its model while the view and controller keep chugging on the main thread. SharedArrayBuffer would mean that all of your state has to be in an array of primitives. I’d rather use objects, classes, strings, etc. without having to serialize them all the time. JS is actually a better fit for threading than C, and in many ways it has similar problems. Unli…

For your parallel search example, the data set has to be extremely large for parallel searching to have a significant improvement.

When does a client-side JS app have access to many GBs of local data that would justify a parallel algorithm? It seems exceedingly rare but maybe you can imagine an example.

If you're talking about a server side app, if your goal is speed, why would you choose JS over C++? It seems more sensible to write the parallel database search in C++ in that case.

As for appropriateness of threading for C over JS: I think the fact that JS is garbage collected makes a threading implementation a nightmare. A naive GC implementation otherwise kills performance: imagine running a parallel computing and having to "stop the world." GC at a conceptual level is inherently "single-threaded" and it will always be a bottleneck in one way or another.

Re: Concurrent JavaScript: It can work

#176

Post by emeryberger »

mschuetz wrote: post #153
pitaj wrote: post #20

Earlier quoted context omitted.

I share your concerns about the usefulness and implementation of this concurrency strategy. In my opinion, concurrency isn't necessary for JS. If web developers want high-performance, concurrent computing, they should push for adding concurrency to WASM. I doubt concurrency could hurt JS, but I just don't see any reason for it that concurrent WASM doesn't fulfill.

I need concurrency to parse and prepare streamed 3D data while keeping the main javascript/render thread fast. WebWorkers are already very useful in that regard.

Obligatory plug for Browsix (http://browsix.org), "Unix in your browser", which already provides concurrency via Unix-like processes and IPC. Processes can communicate with sockets & pipes, and run on separate WebWorkers. (Also, you can directly run complex C/C++ applications that expect a Unix environment.)

Re: Concurrent JavaScript: It can work

#177

Post by zackmorris »

porker wrote: post #156
zackmorris wrote: post #148

I'm late to the party but please for anyone reading this, look into the actor model. Shared mutable state quickly becomes unmaintainanble. It used to be slow to do shared immutable state but that's no longer the case. Today there are many better ways to do shared memory with copy-on-write so data is only copied if it's changed. Think back on history - there are only a handful of computation approaches that have stood…

> there are only a handful of computation approaches that have stood the test of time. Pipes in unix, spreadsheets, data management systems like MS Access or FileMaker. Had concepts from those programs made it into programming, our lives would be a lot simpler today. Can you go into more detail on which concepts from Pipes in unix, spreadsheets, data management systems like MS Access or FileMaker you're thinking of?…

Ya what I was trying to say for each of those is:

Pipes/streams: one way channels between isolated executables

Spreadsheets: the only form of functional programming that's reached mass adoption (equivalent to lisp for the most part)

DBMS: the only form of declarative programming other than the web that's reached mass adoption. In this case the view has two-way binding to the data, but relationships are declarative and the controller has been abstracted into the GUI and event callbacks on buttons etc (controller is the weakest portion of MVC)

All of these concepts could/should make it into mainstream programming languages. Try searching for Redux, Elm, software transactional memory, the Clojure state store, coroutines (which are interchangeable with state machines but without goto).

I believe that we can use all of these techniques without the ugly syntax of functional programming languages like Haskell, Scala, R, etc. For example Elixir is trying to be a kinder, gentler Erlang.

Re: Concurrent JavaScript: It can work

#178

Post by first_amendment »

pizlonator wrote: post #167
first_amendment wrote: post #154

Earlier quoted context omitted.

> I just don't think that we have sufficient evidence to conclude that using type systems to aid the development of concurrent code actually leads to better concurrent code. This is like saying we don't have evidence that evolution is real. Type systems are proof systems. If a type system encodes concurrency safety, and a program is valid under that system, then you can be 100% certain that program doesn't have a rac…

Lol! You would not be successful as a scientist with this attitude. A type system is a proof. But the proof in the type system is not a proof that it’s better to use a type system than not. That’s an entirely separate question. I think that type systems are good at some things. Concurrency isn’t one of them.

I made an argument. What's yours? You just made a statement of opinion without any justification.

Additionally your opinion is wrong, by simple counter example. Rust's type checker already has the ability to prevent data races: https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h... This works today.

Re: Concurrent JavaScript: It can work

#179

Post by zackmorris »

hurricaneSlider wrote: post #152
zackmorris wrote: post #148

I'm late to the party but please for anyone reading this, look into the actor model. Shared mutable state quickly becomes unmaintainanble. It used to be slow to do shared immutable state but that's no longer the case. Today there are many better ways to do shared memory with copy-on-write so data is only copied if it's changed. Think back on history - there are only a handful of computation approaches that have stood…

Hi Zach, I'm working on a implementation of the actor model for node, and since you mentioned it, I was wondering if you would perhaps be able to provide some feedback on it. Still very early days, but making some good progress on a single node implementation.

Ya sure, I could maybe take a look. I have to be honest though that I haven't used the actor model for a project yet. I just get a lot of leverage from its principles when I do shell scripting.

In Node I would be concerned about shared mutable memory. Just curious how you are isolating the actors? Or is that still in the todo stage?

Re: Concurrent JavaScript: It can work

#180

Post by pizlonator »

first_amendment wrote: post #175
pizlonator wrote: post #166

Earlier quoted context omitted.

Imagine having an app that wants to perform a concurrent search on its model while the view and controller keep chugging on the main thread. SharedArrayBuffer would mean that all of your state has to be in an array of primitives. I’d rather use objects, classes, strings, etc. without having to serialize them all the time. JS is actually a better fit for threading than C, and in many ways it has similar problems. Unli…

For your parallel search example, the data set has to be extremely large for parallel searching to have a significant improvement. When does a client-side JS app have access to many GBs of local data that would justify a parallel algorithm? It seems exceedingly rare but maybe you can imagine an example. If you're talking about a server side app, if your goal is speed, why would you choose JS over C++? It seems more s…

Not parallel searching. Concurrent searching.

The data set only has to be large enough that the search takes more than 1/60th of a second. Then it's profitable to do it concurrently.

GC is not single threaded at all. In WebKit, it is concurrent and parallel, and already supports mutable threads accessing the heap (since our JIT threads access the heap). Most of the famous high-performance GC implementations are at least parallel, if not also concurrent. The classic GC algorithms like mark-sweep and semi-space are straight-forward to make work with multiple threads, and they both have straight-forward extensions that support parallelism in the GC and concurrency to the mutator.

Post reply on HN