6 ms·

WebKit does a lot of fine grained parallelism. I think you’re way too casually dismissing how awesome shared memory is.

dbaupp 9y ago
Servo, which pcwalton works on, is largely motivated by the awesomeness of shared memory.
pcwalton 9y ago
With all due respect, no, it doesn't do fine grained parallelism in the areas I described. Do I think it would be impossible to add parallel styling or layout to WebKit? No. Do I think it would be difficult? Absolutely, primarily because of the difficulty of finding all the concurrency hazards in existing objects and making them thread-safe. It would be easier with a type system that automatically checks for and highlights such problems. Such a system is precisely what I'm advocating. And I'm not saying not to use shared memory. I'm saying that shared memory should be controlled by some sort of static or dynamic type system that enforces proper locking or immutability as the case may be. Such a system is hardly a far-fetched idea, as we're successfully using one right now in the style system of nightly Firefox.
- flagxor 9y ago
  It would have been a shame if the OSes on which Firefox runs had similarly limited access to shared memory to one particular "safe" style in the spirit of paternalistic caution. Would Rust/Servo have been possible without access to the raw rope?
  - dbaupp 9y ago
    Rust is a relatively hands-off style of thread-safety: it protects against data races but doesn't try to get things like deadlock freedom that other more restrictive systems require. The benefits apply when using locks, or message passing or even raw atomics (and similarly to higher level libraries like data parallelism in rayon). However, Rust is also explicitly designed to allow access to the "raw rope" when abstractions don't cut it (or when building the abstractions): that is what `unsafe` allows.
    - flagxor 9y ago
      As long as we offer a similar `unsafe` option, a stronger type system around mutability+concurrency might have a range of benefits for JS. Rust's definitely has a number of virtues. A little hard to imagine grafting onto JS though. :-)
  - first_amendment 9y ago
    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-all shared state thread model, which is very likely false. I ask you, what applications does free-for-all shared state make possible that SharedArrayBuffer doesn't make possible?
    - pizlonator 9y ago
      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. Unlike C, JS has memory safety and concurrency wouldn’t break that. Concurrent programming is a lot easier if you can’t corrupt the heap. Like C, JS has some “global” variables like RegExp.lastMatch (C has errno) that need to be made into thread-locals. My proposal includes thread locals so it would be easy to make lastMatch into a getter that loads from a thread local.
      - first_amendment 9y ago
        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.
- pizlonator 9y ago
  JavaScript has no type system currently, other than a trivial one with exactly one type. So, adding concurrency via a type system would be like trying to fit a square peg into a round hole. Also, shared memory with no type system help is a proven technique that is used in shipping software and has been for a long time. This leads me to believe that it would be easier to use our existing full shared memory approach to implementing parallel layout than it would be to use your technique. Just the fact that some research experiment did use a type system and concurrency does not mean that this is actually better than the alternative. It just means that it is an alternative. As for finding concurrency hazards when making things concurrent, you’re sorta talking to the right guy. That’s my bread and butter. Like every hard thing, it becomes easy with practice. Maybe type system help is for people who don’t practice enough.
  - tiles 9y ago
    > Maybe type system help is for people who don’t practice enough. That's like advocating that tests are for people who "can't" write bug free code. Is this the attitude of all JSC developers toward engineering abstractions? I would expect designing a system that JITs third-party code from adversarial parties would lead you to be more cautious about code quality, not less.
    - pizlonator 9y ago
      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 extensive reliance on those areas of C++'s type system that we can use to get hard guarantees. It's not that we don't like types. It's that we use types in an evidence-based way in those places where they actually help us catch bugs.)
      - first_amendment 9y ago
        > 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 race condition bug due to shared state between threads. If a type system can prove buggy concurrent code is invalid code, then by definition it leads to better valid concurrent code.

Servo, which pcwalton works on, is largely motivated by the awesomeness of shared memory.

With all due respect, no, it doesn't do fine grained parallelism in the areas I described. Do I think it would be impossible to add parallel styling or layout to WebKit? No. Do I think it would be difficult? Absolutely, primarily because of the difficulty of finding all the concurrency hazards in existing objects and making them thread-safe. It would be easier with a type system that automatically checks for and highlights such problems. Such a system is precisely what I'm advocating. And I'm not saying not to use shared memory. I'm saying that shared memory should be controlled by some sort of static or dynamic type system that enforces proper locking or immutability as the case may be. Such a system is hardly a far-fetched idea, as we're successfully using one right now in the style system of nightly Firefox.

flagxor 9y ago
It would have been a shame if the OSes on which Firefox runs had similarly limited access to shared memory to one particular "safe" style in the spirit of paternalistic caution. Would Rust/Servo have been possible without access to the raw rope?
- dbaupp 9y ago
  Rust is a relatively hands-off style of thread-safety: it protects against data races but doesn't try to get things like deadlock freedom that other more restrictive systems require. The benefits apply when using locks, or message passing or even raw atomics (and similarly to higher level libraries like data parallelism in rayon). However, Rust is also explicitly designed to allow access to the "raw rope" when abstractions don't cut it (or when building the abstractions): that is what `unsafe` allows.
  - flagxor 9y ago
    As long as we offer a similar `unsafe` option, a stronger type system around mutability+concurrency might have a range of benefits for JS. Rust's definitely has a number of virtues. A little hard to imagine grafting onto JS though. :-)
- first_amendment 9y ago
  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-all shared state thread model, which is very likely false. I ask you, what applications does free-for-all shared state make possible that SharedArrayBuffer doesn't make possible?
  - pizlonator 9y ago
    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. Unlike C, JS has memory safety and concurrency wouldn’t break that. Concurrent programming is a lot easier if you can’t corrupt the heap. Like C, JS has some “global” variables like RegExp.lastMatch (C has errno) that need to be made into thread-locals. My proposal includes thread locals so it would be easy to make lastMatch into a getter that loads from a thread local.
    - first_amendment 9y ago
      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.
pizlonator 9y ago
JavaScript has no type system currently, other than a trivial one with exactly one type. So, adding concurrency via a type system would be like trying to fit a square peg into a round hole. Also, shared memory with no type system help is a proven technique that is used in shipping software and has been for a long time. This leads me to believe that it would be easier to use our existing full shared memory approach to implementing parallel layout than it would be to use your technique. Just the fact that some research experiment did use a type system and concurrency does not mean that this is actually better than the alternative. It just means that it is an alternative. As for finding concurrency hazards when making things concurrent, you’re sorta talking to the right guy. That’s my bread and butter. Like every hard thing, it becomes easy with practice. Maybe type system help is for people who don’t practice enough.
- tiles 9y ago
  > Maybe type system help is for people who don’t practice enough. That's like advocating that tests are for people who "can't" write bug free code. Is this the attitude of all JSC developers toward engineering abstractions? I would expect designing a system that JITs third-party code from adversarial parties would lead you to be more cautious about code quality, not less.
  - pizlonator 9y ago
    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 extensive reliance on those areas of C++'s type system that we can use to get hard guarantees. It's not that we don't like types. It's that we use types in an evidence-based way in those places where they actually help us catch bugs.)
    - first_amendment 9y ago
      > 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 race condition bug due to shared state between threads. If a type system can prove buggy concurrent code is invalid code, then by definition it leads to better valid concurrent code.