I fit into a lot of the special cases here: Developer, gamer, amateur photographer with many gigabytes of RAW files and even I don't feel the need to upgrade systems like I used to. Now it is about an every 3-4 year thing whereas previously it was yearly or more.

for example: random forest, gradient boosting, gam, etc -- you will typically do parameter searches and the models you get are as good as your willingness to wait. Good software will run at a significant fraction of memory bus speed and the faster that bus goes the better your models will be.

eg: most CPU memory traffic is in "cachelines" size chunks so you're best off trying to organize information so you can use all bandwidth! I've a few ideas on this i'm trying to bake into an array/matrix library i hope to release soon. :)

The naive obvious "dot product" matrix mult of two Row Major matrices is 100-1000x slower than somewhat fancier layouts, or even simply transposing the right hand matrix can make a significant difference, let alone more fancy things.

Often the biggest throughput bottleneck for CPU bound algorithms in a numerical setting is the quality of the memory locality (because the CPU can chew through data faster than you can feed it). Its actually really really hard to get C / C++ to help you write code with suitably fancy layouts that are easy to use.

Amusingly, I also think most auto vectorization approaches to SIMD actually miss the best way to use SIMD registers! I've actually some cute small matrix kernels where by using the AVX SIMD registers as a "L0" cache, I get a 1.5x perf boost!

Still I don't see the connection to Haskell, can you elaborate ?

well: 1) i've been slowly working on a numerical computing / data analysis substrate for haskell for over a year now.

2) the haskell c ffi is probably the nicest c ffi you'll ever see. Also pretty fast, basically just a known jump/funcall! And no marshaling overhead too!

3) theres a lot of current and pending over the next year work to make it easy to write HPC grade code using haskell. Some approaches involve interesting libs for runtime code gen (the llvm-general lib for haskell is AMAZING).

Theres also a number of ways where ghc haskell will likely get some great performance improvements for numerical code over the next 1-2 years! (i've a few ideas for improving the native code gen / SIMD support over the next year that I hope to experiment with as time permits)

just plain ole mathematical modeling / machine learning, and associated duct taping the tubes.

I am also going to be releasing the start of a "Numerical Haskell" tool chain sometime (hopefully this fall, but life happens and all that jazz)

I am also going to be releasing the start of a "Numerical Haskell" tool chain sometime (hopefully this fall, but life happens and all that jazz)

Regular users don't know or care about memory management, they don't even close old windows or tabs, its about convenience. That's not a problem in mobile where the need is the mother of invention so mem management is automatic and chrome reopens the tabs you had by itself, but in a desktop environment (specially windows) one wrong click and the session restore in chrome wipes your previous session.

But it was cheap, cheaper than an unlocked iphone and it gets the job done so its ok for her.

I suspect a few people on HN will be reluctant to see their role in this arrangement. ducks

We built really powerful computers and decided the best way to use them was to run web apps consisting of a poor performance scripting language with a poor performance visual-rendering language and half the people who build with it seem to think that anything done in a web browser is free.

"Modern" CSS for even a simple site is pretty silly. So many horribly inefficient rules, sometimes dozens of levels of overwriting properties, etc. And gobs upon gobs of Javascript that does very little but is constantly running, checking input boxes, animating every tiny little detail, doing things that can be done without Javascript, etc.

I have better system performance when running a Windows 7 VM, a semi-bulky image editor, or compiling the kernel than I do with a few bulky webapps in Firefox. And this is on a desktop built just 4 years ago.

I have a light-weight Linux setup that uses 80MB of RAM after logging in. It has 1GB of RAM. I can't run GMail and Facebook Firefox and browse the Internet at the same time with minimal open tabs. It's sad.

I know that some newer frameworks take advantage of GPU features (actually I used to work as a dev in the Windows org) but guess what, GDI is still faster.

As a data point: Safari is using 600+MB now with just HN and GitHub open. It's using more memory than all the other apps (editor, terminal, mail, Rdio, Skype) combined. 600MB is not much by today's standards, but comparatively, is ridiculously wasteful. It's a damn CD.

Hope the Mavericks update improves this a bit since I'm short on RAM on this machine (4GB).

My MBA has 4GB and I constantly forget, because it is enough, and I am constantly surprised that it doesn't have 8GB.

All modern web browsers save and restore sessions across restarts.

I always up-to-date Firefox, so hopefully the memory leaks are minimal. I reboot my Linux machine every month-ish and don't exit Firefox unless necessary. I always keep a few "app" tabs pinned, only a couple of them are heavy. I have 4GB of RAM and turned swap off for an experiment. Sure enough, after a couple weeks of browsing and keeping about 25 tabs open, Firefox's memory consumption would creep up and up and eventually it would crash.

I can only guess/hope that there are memory leaks involved.

Why should they? If a tab's "dormant", the browser can just quiesce JS timeouts and let the tab's memory get swapped out. Not a problem anymore.

That most (all?) web browsers don't do this currently isn't the user's fault.

That's the problem in this type of "PCs are fine, people just don't have to upgrade" argument. (And I've made it myself, before I really worked it through and took stock of just how far tablets have already come.)

The use cases satisfied by an old PC could all be satisfied just as well by today's tablets. Yes, the software support for keyboards, external displays and server-type services isn't quite there. But that's solely a software limitation. Not a limitation of the hardware platform. It will be addressed and more PC sales will disappear.

And the actual remaining PC-justifying use cases are precisely those where an old core2duo isn't "good enough" and simply buying some more RAM or even an SSD isn't going to obviate the need for new hardware for 5+ years.

So inasmuch as people still need PCs, they have to show up in the sales charts. And inasmuch as we don't, mobile devices are going to eat that market as the software evolves.

There's really no way around it.

Frankly, I think android and/or iOS are one good upgrade-cycle away from decimating laptop sales. If either or both really focus on the 'docked' use case -- better support for external displays and keyboard support to facilitate top-flight bulk text entry/editing -- laptops are dead to the general public.

If a student can so much as use a keyboard case and tablet to write a term paper or code up some homework as easily as on a laptop, it's over. And there's no hardware preventing that. It's software. If Microsoft wasn't so inept, they'd have been way out ahead on this.

And, frankly, between the potential of the docked use case and "BYOD" policies, mobile devices could seriously eat into the enterprise desktop market as well.

You build a device cradle, that connects to an external display, power and a keyboard/trackpad, and enables the OS and apps to automatically sense that connection and shift their interfaces accordingly and you'll see how few people truly need a PC anymore.

I think docks have some hurdles to jump in the consumer market, though. They're unsexy - I think most people associate them with boring enterprise computers and boring enterprise work, and they tend to be big and ugly. They're expensive too, considering that most people view them as nothing but plastic with a few connectors and wires inside.

If someone can figure out how to jump those hurdles, though, and make docks sexy to the consumer market, beige-box sales will plummet. Make them smaller, easier, cheaper. Make them less proprietary - at the very least, a Company XYZ consumer dock should be compatible with all/most of of Company XYZ's portable offerings. Make them wireless and automatic (OK, I realize this conflicts with "cheaper")! Let me drop my Win8 tablet on my desk and immediately have it display to my dual monitors and let me use it with my mouse, keyboard, printer, big external drive and wired network connection. Let me press a button and have it display to my TV or play to my big speakers. Have your cake and eat it too.

I mention Win8 specifically because the whole idea of it is that it's a tablet and a desktop OS in one. Why on earth is there no Microsoft-produced drop-in docking solution for the Surface so it can actually be both?! The consumer potential is crazy - got a crusty old desktop PC laying around? Toss it, keep the peripherals, buy a Surface+dock and you've got a new tablet/laptop and desktop. You can "dock" a Surface as-is with two cables (a micro HDMI and a USB hub with all your desktop peripherals wired in), but that leaves out wired network (maybe important), certain peripherals like speakers (maybe important), and power (critical), and even two cables is two too many.

Most people who say they need a PC don't need a beige box, they need a keyboard, mouse and monitors on a desk where they can work. The form factor of the box that the CPU, disk and memory come in doesn't matter when you're at the desk, so it might as well take the form of something you can take with you and use when you're not at the desk: a laptop, tablet or phone.

My tablet can connect to my wifi when I come home and sit at my desk. There's no reason at all why it can't connect to my mouse+keyboard at the same moment; so someone needs to solve the technical problems of it being able to connect to my large monitor wirelessly, and we're set.

The PC market has relied on end users - consumers and business users - for it's growth engine for decades, and that appears to be drying up. One of the reasons for that is outlined in the article, for most use cases we don't need faster.

Faster CPUs, more memory, and faster storage are always welcome. I look forward to the day when Eclipse and other IDEs really start taking advantage of GPU stream processors for indexing and validation.