5 ms·

Apps barely making use of multicore? Maybe in your web world. We would not have been able to ship the apps we've shipped were it not for being able to exploit

Apps barely making use of multicore? Maybe in your web world. We would not have been able to ship the apps we've shipped were it not for being able to exploit shared state concurrency. ... and yes, I think the Facebook app is making heavy use of multicore and SIMD; multicore directly, and SIMD by way of the heavily optimized native frameworks shipped with the device. I've previously made of NEON to get ideal performance out of critical path file decoding on lower end devices, where having those additional CPU cycles available made the difference between stuttering and smooth UI. Stop trying to fit native apps into a box you've defined to match your web-centric experience, where low expectations are simply the norm.

pcwalton 11y ago
If apps were using multicore all over the place, the hardware vendors would have responded by increasing the number of cores on the CPU as they planned to. Instead, they didn't, because people aren't using it. I don't see any particular use the Facebook app would possibly have for multicore. Image and video decoding perhaps, but browsers already multithread those. The point about native frameworks making use of SIMD applies equally to the SIMD that the browser engine components internally use. Finally, I've been writing native code almost exclusively for the past five years.
- nodamage 11y ago
  In this context threading is less about making maximum use of multiple cores and more about "never blocking the main/UI thread". Even on a single core device you usually need to start offloading heavy computation to a background thread to keep the UI responsive. Even today I'll run into websites that lock up a browser tab because they're running a whole mess of Javascript soup (typically jQuery). I know we were promised WebWorkers like 5 years ago but does anyone actually use them?
  - pcwalton 11y ago
    Yes, I fully agree that this is one of the biggest problems. Web developers don't treat Web Workers like they treat Blocks in Objective-C, and this is causing performance problems. On the engine side, we have to figure out how to make workers and off-main-thread work just as easy to use as in Objective-C and Java--I believe this is doable with effort.
- teacup50 11y ago
  Multicore isn't free in a battery constrained device, and yet devices are multicore. The fact that you don't have an 8 core phone doesn't mean multicore concurrency isn't used. There are all sorts of things that benefit from multicore concurrency; a simple example is keeping data handling (including SQLite query execution, which has a non-zero cost) off of the UI thread that's responsible for keeping table scrolling glossy smooth. You may have been writing native code, but you clearly haven't been shipping high gloss end-user applications on mobile devices.
  - pcwalton 11y ago
    Concurrency is not parallelism, and you're conflating the two. Multicore is for parallelism: literally doing multiple tasks at the same time. Apps are not making good use of parallelism. Apps certainly do make good use of concurrency--your example of moving background work off the UI thread is an example of that--and the Web needs to support that better. But that's not a parallelism problem, and it's not related to multicore: note that what you describe is a good idea even with only one CPU. > but you clearly haven't been shipping high gloss end-user applications on mobile devices. Yes, I have. Can I suggest you stop inserting these random jabs into your posts?

pcwalton 11y ago

If apps were using multicore all over the place, the hardware vendors would have responded by increasing the number of cores on the CPU as they planned to. Instead, they didn't, because people aren't using it. I don't see any particular use the Facebook app would possibly have for multicore. Image and video decoding perhaps, but browsers already multithread those. The point about native frameworks making use of SIMD applies equally to the SIMD that the browser engine components internally use. Finally, I've been writing native code almost exclusively for the past five years.

nodamage 11y ago
In this context threading is less about making maximum use of multiple cores and more about "never blocking the main/UI thread". Even on a single core device you usually need to start offloading heavy computation to a background thread to keep the UI responsive. Even today I'll run into websites that lock up a browser tab because they're running a whole mess of Javascript soup (typically jQuery). I know we were promised WebWorkers like 5 years ago but does anyone actually use them?
- pcwalton 11y ago
  Yes, I fully agree that this is one of the biggest problems. Web developers don't treat Web Workers like they treat Blocks in Objective-C, and this is causing performance problems. On the engine side, we have to figure out how to make workers and off-main-thread work just as easy to use as in Objective-C and Java--I believe this is doable with effort.
teacup50 11y ago
Multicore isn't free in a battery constrained device, and yet devices are multicore. The fact that you don't have an 8 core phone doesn't mean multicore concurrency isn't used. There are all sorts of things that benefit from multicore concurrency; a simple example is keeping data handling (including SQLite query execution, which has a non-zero cost) off of the UI thread that's responsible for keeping table scrolling glossy smooth. You may have been writing native code, but you clearly haven't been shipping high gloss end-user applications on mobile devices.
- pcwalton 11y ago
  Concurrency is not parallelism, and you're conflating the two. Multicore is for parallelism: literally doing multiple tasks at the same time. Apps are not making good use of parallelism. Apps certainly do make good use of concurrency--your example of moving background work off the UI thread is an example of that--and the Web needs to support that better. But that's not a parallelism problem, and it's not related to multicore: note that what you describe is a good idea even with only one CPU. > but you clearly haven't been shipping high gloss end-user applications on mobile devices. Yes, I have. Can I suggest you stop inserting these random jabs into your posts?