undefined | Better HN

0 pointspcwalton10y ago0 comments

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.

0 comments

4 comments · 2 top-level

nodamage10y ago· 1 in thread

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?

pcwaltonOP10y 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.

teacup5010y ago· 1 in thread

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.

pcwaltonOP10y 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?

j / k navigate · click thread line to collapse

0 comments

4 comments · 2 top-level

nodamage10y ago· 1 in thread

pcwaltonOP10y ago

teacup5010y ago· 1 in thread

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.

You may have been writing native code, but you clearly haven't been shipping high gloss end-user applications on mobile devices.

pcwaltonOP10y ago

> 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?

j / k navigate · click thread line to collapse