Hacker News new | ask | show | jobs
by axod 6426 days ago
And as more things are run on servers, and less on clients, do we need to go faster on the client?
4 comments

It's not necessarily all about speed (or what theorists would refer to as single-task completion). It's also about increasing throughput.

Google adds a pinch of concurrency to its web browser (each tab running in another thread) and it improves the client side experience.

I don't think throughput is a barrier at the moment.

The main touted benefit I've heard of Chromium's tab-threading is insulation, so if one tab crashes it doesn't bring the whole browser down.

Actually, I'd say the main benefit is that closing tabs actually releases memory because those processes die.
New computers are coming with gigabytes of ram, I have 2. On the other hand, I rather enjoyed watching a quicktime crash take down only 1 tab. I kept loading it repeatedly.
I have 4, that means nothing when the browser keeps bloating up and taking gigs itself because opening and closing lots of tabs all day long fragments the memory so badly that it can't release ram back to the OS when you close some tabs.
In Chrome each tab is a separate process, which is mostly for stability (if one crashes it doesn't take down the whole browser).
Maybe we do: faster client-side AJAX would create a much better user experience... but how much this is needed, I don't know. Maybe it doesn't really matter?

At any rate, speed can be increased substantially without faster hardware, but with: (1) efficient implementations of javascript (Chromium); (2) faster Flash (AS3 + AIR); (3) web-friendlier Java (JavaFX); or even Sliverlight.

But the nice thing about faster hardware is you get faster apps without rewriting or learning new tech - opps, unless that faster hardware is many-core[⁎]...

Another reason to not need many-core is that desktop apps are already fast enough for the staples (word processing, spreadsheets). Hence the rise of sub-notebooks, the iPhone, and the best-selling games console being by far the least powerful (wii).

[⁎] many-core (as opposed to multi-core) technically means heaps of processors - tens or hundreds. It is a qualitatively different situation from one thread per processor.

Pretty much anyone working with 3D, Image processing, AI and in many simulation areas will hope for more speed for a few more years.
Extracting parallelism from rendering code is well-understood and has been for a decade or more. Intel is hyping all this as if it's something new but really it's well-understood stuff being implemented inside one box instead of being spread across many.
you need to stop fighting the future