5 ms·

Developers need more performance. Video editors need more performance. CGI artists need more performance. Servers need more performance. Phones need more perfor

Developers need more performance. Video editors need more performance. CGI artists need more performance. Servers need more performance. Phones need more performance. In contrast, desktop computers for general-purpose needs are already adequate. Word processing, YouTube, Facebook, and non-enthusiast gaming has pretty modest needs that are easily met by a mid-range i5. The only thing that will put pressure on that is entirely new applications that are much more demanding. VR could be one of those things, but I don't see it as a significant market maker inside of a decade. The same goes for AI.

mpweiher 10y ago
> Developers need more performance. But do we need more hardware performance or more software performance? My main point was that things are slow mostly not because the hardware is inadequate, but instead because the software is inadequate, and the software is inadequate because developers have become lazy, because the hardware used to bail us out for free.
- astrodust 10y ago
  This is the laziest argument ever made. Hardware is continuing to improve in performance, it's just that the gains are focused on things like power efficiency rather than brute force. Likewise, software continues to improve in performance: JavaScript engines, to use but one example, are consistently getting faster. If you want to live in some grim world where everything is shit and nothing will ever get fixed, knock yourself out, but the truth of the matter is there's relentless and significant improvements being made across the board.
  - mpweiher 10y ago
    > JavaScript engines, to use but one example, are consistently getting faster. JavaScript is your example for efficient software? Hmm... The only thing happening with JavaScript is trying to optimize away all the incredible inefficiency of the original design, at tremendous expense. And the reason we are doing this in the first place is that we are now re-implementing all sorts of desktop software in JavaScript...typically at least an order of magnitude bigger and slower. So thanks for making my point for me. EDIT: And I am sorry that you perceive my message as "grim". I personally find it hopeful, because we have massive untapped power lurking in the machines we already have, no Intel-provided improvements needed.
    - pcwalton 10y ago
      JS is quite a bit faster than, say, idiomatic Objective-C. Or Java run through Dalvik. Personally, I don't see why everyone focuses on JavaScript as a massive source of inefficiency compared to, say, PHP. Not to mention the rose-colored glasses we see the past in: folks back in the '90s used to work day in and day out with VB6 (or even interpreted Java) apps.
      - candiodari 10y ago
        Comparing browser games with Dalvik games on 1/4th the cpu/gpu as on my desktop, I feel obliged to point out: Nope. Now this may be that browsers just suck at graphics, or at games in general. Perhaps. Does it matter ? No. Javascript does not match Java in speed, not regular java, nor Dalvik. Comparing node.js apps with PHP apps, it doesn't match PHP performance either.
        pcwalton 10y ago
        > Now this may be that browsers just suck at graphics, or at games in general. Perhaps. Does it matter ? No. Yes, it does, because I'm talking about JavaScript. Not about the entire browser graphics stack (which, by the way, is architecturally better than that of Android). > Javascript does not match Java in speed, not regular java, nor Dalvik. No, Dalvik is slow compared to JS. Its trace based architecture is roughly on par with JS engines in 2009. > Comparing node.js apps with PHP apps, it doesn't match PHP performance either. Zend doesn't even have a JIT.
        candiodari 10y ago
        Well, that may be true, and a big plus for the developers of those systems, but if the results aren't there, what's the point ? Even if it's browser APIs rather than directly the language/interpreters ...
      - mpweiher 10y ago
        > JS is quite a bit faster than, say, idiomatic Objective-C. (a) That depends hugely on what you consider "idiomatic" Objective-C and (b) yeah, that's kind of my point. If you write Objective-C in the style that is currently popular and propagated, treating it as a unified programming language like JS, Java or Smalltalk, you're going to be slow. In my book[1], I show how easy it is to be slower not just than JS or Java, but even slower than a byte-coded Smalltalk interpreter or Ruby. And the sad part is that it's not even particularly expressive! On the other hand, I also show how you can use the original Objective-C style, let's call it "Software-ICs", to create an XML parser faster than libxml and with a much nicer interface, or a Postscript interpreter that uses Objective-C objects as Postscript objects and is still faster than Adobe's interpreter (written in C) for most basic language stuff like arithmetic and loops (it doesn't do the graphics itself, so comparing those numbers would be pointless). In fact, said Postscript interpreter, written in Objective-C, is faster at arithmetic than the "bad" Objective-C style, while doing automatic arithmetic promotion, so being safer. The "Software-IC" style for Objective-C involves fast components written in C connected at the architectural level by dynamic messaging. It is highly idiomatic, convenient, fun and fast as hell. Interestingly, variations of that basic style are being rediscovered these days by the people doing "imperative shell, functional core". See for example Gary Bernhard's talk[2] and then tell me that the final picture doesn't look almost exactly like the pictures Cox drew of Software-ICs (and remember that Cox also said that (a) messaging didn't have to be synchronous and (b) the implementation language for the Software ICs didn't matter much). The Unix tools are also very similar, with fast components written in C connected at the architectural level with pipes. This is also the reason why I think my Objective-Smalltalk language[3] actually has a good chance of enabling very fast programs despite the very high level of abstraction it is aiming for. Being able to pick an appropriate interconnection style and fast components is the key to fast software. Back to the original point, we are leaving orders of magnitude of performance on the table, quite frequently for no particular reason. And as I wrote elsewhere, I actually think this current point we have reached is good for software and for software people, because we can get that performance quite easily by writing decent code, and writing decent code is starting to matter more again. Just like I think the end of Moore's law might finally break the stranglehold Intel has had on hardware architecture, so innovative architectures (remember the Transputer[4]?) have a chance and aren't clobbered by Intel's next fab-step. Speaking of innovative hardware architecture, has there been any new news on the Mill? Interesting times. Anyway, I didn't bring up JavaScript, this problem is everywhere. I just thought that bringing it up as a counterpoint was...humorous. [1] Did I mention my book? g https://www.pearsonhighered.com/program/Weiher-i-OS-and-mac-OS-Performance-Tuning-Cocoa-Cocoa-Touch-Objective-C-and-Swift/PGM161424.html https://www.pearsonhighered.com/program/Weiher-i-OS-and-mac-... [2] https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries [3] http://objective.st/ http://objective.st/ [4] https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer
  - usrusr 10y ago
    > JavaScript engines, to use but one example, are consistently getting faster. When was the last time you where really impressed with https://arewefastyet.com/ https://arewefastyet.com/ ? Recent improvements are looking more like stragglers catching up with the state of the art than like the state of the art improving much. This is a very good thing, but it is not consistently getting faster. More like "getting more consistently fast". Good, but not the same. Actually it seems to be the exact same pattern of approaching a wall as we see (and lament) with desktop CPUs.
  - anexprogrammer 10y ago
    Rather missing the point that we've replaced much native software with thin clients running JS in a browser or pretending to be an app. Whether it needs to be or not. For many reasons - multi device support, convenience, data harvesting, lock in. Performance isn't something we generally get now everything becomes network constrained rather than CPU or IO. So yeah it's being fixed because it has to be, because it's a terrible experience in comparison. I don't deny that often the convenience far outweighs the loss of performance and latency. You can't avoid the fact it's heavily skewed the market against those needing native power on the desktop. If you're doing things that need that, the last 5 years have been rather underwhelming progress wise.
  - flukus 10y ago
    > Likewise, software continues to improve in performance: JavaScript engines, to use but one example, are consistently getting faster. That's the point. We've seen hardware improve but we've had a net loss of performance because a lot of stuff has moved to web apps and other "higher level" languages.
  - josteink 10y ago
    > JavaScript engines, to use but one example, are consistently getting faster. And now people write basic user-space tools in Javascript instead of C, with a basic 100 libraries bolted on as dependencies, where only 0.1% of the code is ever used, but you'll also need to boot the JS runtime before any of this code even runs. Guess which tool is faster. The C one or the JS one? I'm not saying "Do everything in C" (I'm rather in the opposite camp), but he does have a quite valid argument there.
- nightski 10y ago
  That's great and all, and damn them for being lazy! But you know, it's going to take a lot of time and money to fix that problem assuming it is ever fixed at all. In the mean time I'll take the nice hardware upgrades.
  - pjmlp 10y ago
    We are already witnessing it with AOT compilation to native code in Java and .NET, which should never have been a JIT based runtime to start with.
- johansch 10y ago
  We need both.
  - mpweiher 10y ago
    "Software gets slower faster than hardware gets faster" -- Wirth's law. So it seems you get to pick one. And of course, the observation is that we're mostly no longer getting faster hardware.
    - johansch 10y ago
      Only software other people write. :P
- z3t4 10y ago
  Real programmers program in machine code, although you can get away with using assembler and still call yourself a programmer now a days. Heck I even heard about someone using C who called herself a programmer. These new processors allow non-programmers to write software and use high level languages that make you more productive.
jonknee 10y ago
> In contrast, desktop computers for general-purpose needs are already adequate. Word processing, YouTube, Facebook, and non-enthusiast gaming has pretty modest needs that are easily met by a mid-range i5. OK, but that has been the case for a long time. Microsoft Word users are never the market for the highest end desktop CPUs.
swombat 10y ago
> In contrast, desktop computers for general-purpose needs are already adequate. This falls down on the word "general purpose". What is general purpose? And what is general purpose today vs tomorrow? I put it to you that high definition VR and AR, which currently stretch the best consumer machines, are going to be part of "general purpose" as soon as people can put out affordable mass market hardware that supports it. General purpose expands to use the hardware it has available.
- astrodust 10y ago
  Not really. This is the fundamental principle of technology disruption. At some point one paradigm over-serves the market to such a degree that a new, less functional entrant comes in and starts to steal away market share. This happened most dramatically with hard disks, where 8" drives lost way to 5 1/4" even though they took a hit in storage capacity. Later 3 1/2" drives nibbled away at that even further, with the same penalties. Notebook-sized drives ate away at that, too, despite their limited capacity. Every time the driving factor was not performance or capacity, but convenience. Lugging a twenty pound hard drive around in your laptop wouldn't make any sense even if it could hold 400TB of data. Desktops yielded to notebooks, notebooks yielded to phones and tablets. General purpose migrates to the most convenient solution that's adequate for their needs.
  - gaius 10y ago
    Except that the 3.5" disks were not only smaller but higher capacity and more robust than 5.25".
- bobajeff 10y ago
  I put it to you that VR and AR are not going to be general purpose, at least not in our lifetime. I even doubt there will even be a significant niche for either technology as they remain at best a novelty and at worst an expensive gimmick. What people want (and have always wanted) from VR* will be out of reach for some time. *You can't feel virtual objects or move freely in a virtual world (without being hendored by the physical world).
7952 10y ago
Viewing a document or PDF can be remarkably slow. And large image heavy documents are pretty common. Of course that is not always entirely CPU bound, but it often is. Also, a lot of the promise of computers is the ability to process things quickly. If a "big data" task takes 1 sec to run you can afford some trial and error. Increased performance should make software usable by more people with less training.
interpol_p 10y ago
But performance from where? The single biggest performance increase I've experienced in the last decade has been due to the move to SSD. Video editors and CGI artists need more GPU and IO performance. It's what gives them real-time feedback. Developers need fast IO (I have slow compile times, but I rarely desire a new CPU to fix that). The CPU has largely become irrelevant, performance wise. It's great when you hit the final render button on a video, or 3D scene, or when you're compiling code. But those actions constitute a minority of our interactions with computers.
- pcwalton 10y ago
  > The CPU has largely become irrelevant, performance wise. It's great when you hit the final render button on a video, or 3D scene, or when you're compiling code. But those actions constitute a minority of our interactions with computers. Read any HN thread full of complaints about browsers and you'll see otherwise.
- aianus 10y ago
  > Developers need fast IO (I have slow compile times, but I rarely desire a new CPU to fix that). Compile times are almost always CPU-bound. Put all your code and headers/libs on a ramdisk [0] and hit compile and see how much faster it is. My bet is, not much. [0] https://www.jamescoyle.net/how-to/943-create-a-ram-disk-in-linux https://www.jamescoyle.net/how-to/943-create-a-ram-disk-in-l... (just an example)
  - interpol_p 10y ago
    I acknowledged compile times are CPU bound. I'm just saying that I'll take fast IO over faster compile times any day, for development. I want any data I access to appear instantly. Compilation often happens in the background and only very occasionally does it specifically block me from working. Slow IO, however, used to block me from working constantly.
nsxwolf 10y ago
I'm pretty sure the only thing that's ever going to make the performance of Eclipse and IntelliJ IDEs tolerable is gains in raw single core performance, so it can't get here soon enough.
majewsky 10y ago
> Word processing, YouTube, Facebook, and non-enthusiast gaming has pretty modest needs that are easily met by a mid-range i5. You can go lower than that. When I didn't do enthusiast gaming, my desktop PC was an Intel NUC with an Ivy Bridge low-power Core i3 and its integrated Intel HD Graphics. That thing could easily do Portal 2 at 720p on acceptable niceness settings, and Minecraft at 1080p30. Video playback and browsing was perfectly smooth at 1080p, too.

mpweiher 10y ago

> Developers need more performance. But do we need more hardware performance or more software performance? My main point was that things are slow mostly not because the hardware is inadequate, but instead because the software is inadequate, and the software is inadequate because developers have become lazy, because the hardware used to bail us out for free.

astrodust 10y ago
This is the laziest argument ever made. Hardware is continuing to improve in performance, it's just that the gains are focused on things like power efficiency rather than brute force. Likewise, software continues to improve in performance: JavaScript engines, to use but one example, are consistently getting faster. If you want to live in some grim world where everything is shit and nothing will ever get fixed, knock yourself out, but the truth of the matter is there's relentless and significant improvements being made across the board.
- mpweiher 10y ago
  > JavaScript engines, to use but one example, are consistently getting faster. JavaScript is your example for efficient software? Hmm... The only thing happening with JavaScript is trying to optimize away all the incredible inefficiency of the original design, at tremendous expense. And the reason we are doing this in the first place is that we are now re-implementing all sorts of desktop software in JavaScript...typically at least an order of magnitude bigger and slower. So thanks for making my point for me. EDIT: And I am sorry that you perceive my message as "grim". I personally find it hopeful, because we have massive untapped power lurking in the machines we already have, no Intel-provided improvements needed.
  - pcwalton 10y ago
    JS is quite a bit faster than, say, idiomatic Objective-C. Or Java run through Dalvik. Personally, I don't see why everyone focuses on JavaScript as a massive source of inefficiency compared to, say, PHP. Not to mention the rose-colored glasses we see the past in: folks back in the '90s used to work day in and day out with VB6 (or even interpreted Java) apps.
    - candiodari 10y ago
      Comparing browser games with Dalvik games on 1/4th the cpu/gpu as on my desktop, I feel obliged to point out: Nope. Now this may be that browsers just suck at graphics, or at games in general. Perhaps. Does it matter ? No. Javascript does not match Java in speed, not regular java, nor Dalvik. Comparing node.js apps with PHP apps, it doesn't match PHP performance either.
      - pcwalton 10y ago
        > Now this may be that browsers just suck at graphics, or at games in general. Perhaps. Does it matter ? No. Yes, it does, because I'm talking about JavaScript. Not about the entire browser graphics stack (which, by the way, is architecturally better than that of Android). > Javascript does not match Java in speed, not regular java, nor Dalvik. No, Dalvik is slow compared to JS. Its trace based architecture is roughly on par with JS engines in 2009. > Comparing node.js apps with PHP apps, it doesn't match PHP performance either. Zend doesn't even have a JIT.
        candiodari 10y ago
        Well, that may be true, and a big plus for the developers of those systems, but if the results aren't there, what's the point ? Even if it's browser APIs rather than directly the language/interpreters ...
    - mpweiher 10y ago
      > JS is quite a bit faster than, say, idiomatic Objective-C. (a) That depends hugely on what you consider "idiomatic" Objective-C and (b) yeah, that's kind of my point. If you write Objective-C in the style that is currently popular and propagated, treating it as a unified programming language like JS, Java or Smalltalk, you're going to be slow. In my book[1], I show how easy it is to be slower not just than JS or Java, but even slower than a byte-coded Smalltalk interpreter or Ruby. And the sad part is that it's not even particularly expressive! On the other hand, I also show how you can use the original Objective-C style, let's call it "Software-ICs", to create an XML parser faster than libxml and with a much nicer interface, or a Postscript interpreter that uses Objective-C objects as Postscript objects and is still faster than Adobe's interpreter (written in C) for most basic language stuff like arithmetic and loops (it doesn't do the graphics itself, so comparing those numbers would be pointless). In fact, said Postscript interpreter, written in Objective-C, is faster at arithmetic than the "bad" Objective-C style, while doing automatic arithmetic promotion, so being safer. The "Software-IC" style for Objective-C involves fast components written in C connected at the architectural level by dynamic messaging. It is highly idiomatic, convenient, fun and fast as hell. Interestingly, variations of that basic style are being rediscovered these days by the people doing "imperative shell, functional core". See for example Gary Bernhard's talk[2] and then tell me that the final picture doesn't look almost exactly like the pictures Cox drew of Software-ICs (and remember that Cox also said that (a) messaging didn't have to be synchronous and (b) the implementation language for the Software ICs didn't matter much). The Unix tools are also very similar, with fast components written in C connected at the architectural level with pipes. This is also the reason why I think my Objective-Smalltalk language[3] actually has a good chance of enabling very fast programs despite the very high level of abstraction it is aiming for. Being able to pick an appropriate interconnection style and fast components is the key to fast software. Back to the original point, we are leaving orders of magnitude of performance on the table, quite frequently for no particular reason. And as I wrote elsewhere, I actually think this current point we have reached is good for software and for software people, because we can get that performance quite easily by writing decent code, and writing decent code is starting to matter more again. Just like I think the end of Moore's law might finally break the stranglehold Intel has had on hardware architecture, so innovative architectures (remember the Transputer[4]?) have a chance and aren't clobbered by Intel's next fab-step. Speaking of innovative hardware architecture, has there been any new news on the Mill? Interesting times. Anyway, I didn't bring up JavaScript, this problem is everywhere. I just thought that bringing it up as a counterpoint was...humorous. [1] Did I mention my book? g https://www.pearsonhighered.com/program/Weiher-i-OS-and-mac-OS-Performance-Tuning-Cocoa-Cocoa-Touch-Objective-C-and-Swift/PGM161424.html https://www.pearsonhighered.com/program/Weiher-i-OS-and-mac-... [2] https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries [3] http://objective.st/ http://objective.st/ [4] https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer
- usrusr 10y ago
  > JavaScript engines, to use but one example, are consistently getting faster. When was the last time you where really impressed with https://arewefastyet.com/ https://arewefastyet.com/ ? Recent improvements are looking more like stragglers catching up with the state of the art than like the state of the art improving much. This is a very good thing, but it is not consistently getting faster. More like "getting more consistently fast". Good, but not the same. Actually it seems to be the exact same pattern of approaching a wall as we see (and lament) with desktop CPUs.
- anexprogrammer 10y ago
  Rather missing the point that we've replaced much native software with thin clients running JS in a browser or pretending to be an app. Whether it needs to be or not. For many reasons - multi device support, convenience, data harvesting, lock in. Performance isn't something we generally get now everything becomes network constrained rather than CPU or IO. So yeah it's being fixed because it has to be, because it's a terrible experience in comparison. I don't deny that often the convenience far outweighs the loss of performance and latency. You can't avoid the fact it's heavily skewed the market against those needing native power on the desktop. If you're doing things that need that, the last 5 years have been rather underwhelming progress wise.
- flukus 10y ago
  > Likewise, software continues to improve in performance: JavaScript engines, to use but one example, are consistently getting faster. That's the point. We've seen hardware improve but we've had a net loss of performance because a lot of stuff has moved to web apps and other "higher level" languages.
- josteink 10y ago
  > JavaScript engines, to use but one example, are consistently getting faster. And now people write basic user-space tools in Javascript instead of C, with a basic 100 libraries bolted on as dependencies, where only 0.1% of the code is ever used, but you'll also need to boot the JS runtime before any of this code even runs. Guess which tool is faster. The C one or the JS one? I'm not saying "Do everything in C" (I'm rather in the opposite camp), but he does have a quite valid argument there.
nightski 10y ago
That's great and all, and damn them for being lazy! But you know, it's going to take a lot of time and money to fix that problem assuming it is ever fixed at all. In the mean time I'll take the nice hardware upgrades.
- pjmlp 10y ago
  We are already witnessing it with AOT compilation to native code in Java and .NET, which should never have been a JIT based runtime to start with.
johansch 10y ago
We need both.
- mpweiher 10y ago
  "Software gets slower faster than hardware gets faster" -- Wirth's law. So it seems you get to pick one. And of course, the observation is that we're mostly no longer getting faster hardware.
  - johansch 10y ago
    Only software other people write. :P
z3t4 10y ago
Real programmers program in machine code, although you can get away with using assembler and still call yourself a programmer now a days. Heck I even heard about someone using C who called herself a programmer. These new processors allow non-programmers to write software and use high level languages that make you more productive.

jonknee 10y ago

> In contrast, desktop computers for general-purpose needs are already adequate. Word processing, YouTube, Facebook, and non-enthusiast gaming has pretty modest needs that are easily met by a mid-range i5. OK, but that has been the case for a long time. Microsoft Word users are never the market for the highest end desktop CPUs.

swombat 10y ago

> In contrast, desktop computers for general-purpose needs are already adequate. This falls down on the word "general purpose". What is general purpose? And what is general purpose today vs tomorrow? I put it to you that high definition VR and AR, which currently stretch the best consumer machines, are going to be part of "general purpose" as soon as people can put out affordable mass market hardware that supports it. General purpose expands to use the hardware it has available.

astrodust 10y ago
Not really. This is the fundamental principle of technology disruption. At some point one paradigm over-serves the market to such a degree that a new, less functional entrant comes in and starts to steal away market share. This happened most dramatically with hard disks, where 8" drives lost way to 5 1/4" even though they took a hit in storage capacity. Later 3 1/2" drives nibbled away at that even further, with the same penalties. Notebook-sized drives ate away at that, too, despite their limited capacity. Every time the driving factor was not performance or capacity, but convenience. Lugging a twenty pound hard drive around in your laptop wouldn't make any sense even if it could hold 400TB of data. Desktops yielded to notebooks, notebooks yielded to phones and tablets. General purpose migrates to the most convenient solution that's adequate for their needs.
- gaius 10y ago
  Except that the 3.5" disks were not only smaller but higher capacity and more robust than 5.25".
bobajeff 10y ago
I put it to you that VR and AR are not going to be general purpose, at least not in our lifetime. I even doubt there will even be a significant niche for either technology as they remain at best a novelty and at worst an expensive gimmick. What people want (and have always wanted) from VR* will be out of reach for some time. *You can't feel virtual objects or move freely in a virtual world (without being hendored by the physical world).

7952 10y ago

Viewing a document or PDF can be remarkably slow. And large image heavy documents are pretty common. Of course that is not always entirely CPU bound, but it often is. Also, a lot of the promise of computers is the ability to process things quickly. If a "big data" task takes 1 sec to run you can afford some trial and error. Increased performance should make software usable by more people with less training.

interpol_p 10y ago

But performance from where? The single biggest performance increase I've experienced in the last decade has been due to the move to SSD. Video editors and CGI artists need more GPU and IO performance. It's what gives them real-time feedback. Developers need fast IO (I have slow compile times, but I rarely desire a new CPU to fix that). The CPU has largely become irrelevant, performance wise. It's great when you hit the final render button on a video, or 3D scene, or when you're compiling code. But those actions constitute a minority of our interactions with computers.

pcwalton 10y ago
> The CPU has largely become irrelevant, performance wise. It's great when you hit the final render button on a video, or 3D scene, or when you're compiling code. But those actions constitute a minority of our interactions with computers. Read any HN thread full of complaints about browsers and you'll see otherwise.
aianus 10y ago
> Developers need fast IO (I have slow compile times, but I rarely desire a new CPU to fix that). Compile times are almost always CPU-bound. Put all your code and headers/libs on a ramdisk [0] and hit compile and see how much faster it is. My bet is, not much. [0] https://www.jamescoyle.net/how-to/943-create-a-ram-disk-in-linux https://www.jamescoyle.net/how-to/943-create-a-ram-disk-in-l... (just an example)
- interpol_p 10y ago
  I acknowledged compile times are CPU bound. I'm just saying that I'll take fast IO over faster compile times any day, for development. I want any data I access to appear instantly. Compilation often happens in the background and only very occasionally does it specifically block me from working. Slow IO, however, used to block me from working constantly.

nsxwolf 10y ago

I'm pretty sure the only thing that's ever going to make the performance of Eclipse and IntelliJ IDEs tolerable is gains in raw single core performance, so it can't get here soon enough.

majewsky 10y ago

> Word processing, YouTube, Facebook, and non-enthusiast gaming has pretty modest needs that are easily met by a mid-range i5. You can go lower than that. When I didn't do enthusiast gaming, my desktop PC was an Intel NUC with an Ivy Bridge low-power Core i3 and its integrated Intel HD Graphics. That thing could easily do Portal 2 at 720p on acceptable niceness settings, and Minecraft at 1080p30. Video playback and browsing was perfectly smooth at 1080p, too.