5 ms·
A concept a High Performance Computing professor told me once: A program which is memory intensive must be slower then one which needs little memory -- just bec
by ktpsns 8y ago
A concept a High Performance Computing professor told me once: A program which is memory intensive must be slower then one which needs little memory -- just because load/write operations from the CPU take time.
That's one of the reasons why some bloated contemporary desktop software (i.e. Slack) feels as fast as its historic counterpart did in 1995 (i.e. our MSN/ICQ clients back in these days).
- fwip 8y agoThat's a nice sound bite, but isn't really true. There are many cases where we increase memory usage for faster software. Side note, lessons from HPC aren't really that applicable for chat programs.
- inetknght 8y agoFaster, or perhaps more features.
- vvanders 8y agoConversely cache misses are painful and largely haven't gotten faster over the years.
- mbreese 8y agoExactly. And the reason why programs that use a lot of memory might feel slower than one with a little is that cache miss rate. Adding memory often makes an entire system faster (again, because you can cache things in the faster RAM rather than paging out to disk). But for two comparable programs, I could see the argument that the lower-memory footprint program would be faster. (For comparable programs).
- vvanders 8y agoYup, as DDR clock speed increased so have CAS timings.
- fwip 8y agoIf the algorithms are otherwise identical, sure. Often the memory being used is doing things like pre-loading information from disk or the network before it's needed, or caching results for reuse. Or it's storing the information in a faster but less dense data structure - kind of like denormalizing a database for performance reasons.
- segfaultbuserr 8y agoIt's a serious problem in compiler optimization. In the ideal world, a program with loop unrolling and vectorization should always be faster, but in practice, the bigger binary size induces cache misses and may produce a slower problem. Time goes by, and compilers keep adding increasingly complex techniques based on space/time tradeoffs, making the problem trickier. Historically, under some circumstances, a problem compiled with -Os, may paradoxically be faster than -O2, and -O2 may be faster than -O3. I think the situation is getting better now, and the optimizing level mostly works as advertised. But there's still some problems in automatic loop vectorization.
- greglindahl 8y agoWhat's the paradox? The compiler simply can't tell.
- 0815test 8y ago> In the ideal world, a program with loop unrolling and vectorization should always be faster, but in practice, the bigger binary size induces cache misses and may produce a slower problem. The solution is to use abstract, arbitrary vectors in the ISA instead of packed SIMD and unrolled loops. RISC-V gets this right with their V extension.
- greglindahl 8y agoThere are many different kinds of loop unrolling, and RISC-V's V extension is not the only one. Itanium had the same issue: the loop unrolling assist in the instruction set was not viewed by many compiler people as being sufficient.
- colejohnson66 8y agoForwardCom has abitrary length vector support. http://www.forwardcom.info/ http://www.forwardcom.info/ https://news.ycombinator.com/item?id=19340267 https://news.ycombinator.com/item?id=19340267
- NullPrefix 8y ago>we increase memory usage for faster software. We increase memory usage for faster software development.
- larrik 8y agoNo, lots of algorithms and data structures use more space to provide more speed. It's not simple laziness.
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- FullyFunctional 8y agoConstraint solvers comes to mind. It's pretty much the most memory hungry application I can think of, though some of the VLSA EDA tools need triple digit GBs of memory to do anything.
- tonyarkles 8y agoI don’t think that’s what Slack is doing here though :) I’m totally with you for things that are actually doing serious numeric/algorithmic work. Matrix inversion runs a helluva lot faster when the whole matrix fits in RAM. And there are undoubtedly lots of places where you can use different algorithms for the same problem that can trade off memory usage and computational complexity.
- fuzz4lyfe 8y agoIt does happen obviously: https://en.wikipedia.org/wiki/Space%E2%80%93time_tradeoff https://en.wikipedia.org/wiki/Space%E2%80%93time_tradeoff But yes, running another browser + javascript interpreter on a machine that already has a browser + javascript interpreter running isn't what that article is talking about.
- jsharf 8y ago
- cbhl 8y agoReading from RAM is certainly faster than disk, but reading less is faster than reading either from RAM or from disk. Chrome is a big application that tries to be everything for all people. If Desktop performance mattered to companies, folks would strip out the browser and use native components. (This is literally React Native on mobile, even if programmers are still mostly writing in JavaScript instead of C++ or Objective C or Swift.)
- larrik 8y ago> Reading from RAM is certainly faster than disk, but reading less is faster than reading either from RAM or from disk. This is just not true in a lot of ways. For example, you can use memory to store the same data in multiple ways, and then you get blistering fast access, whereas if you only store it in a single way, you may get a range of read performance between "as good" to "really really bad". I understand why what you said sounds true, but it's not that simple at all.
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- cbhl 8y agoYes, you're right. In hindsight, I wish I could delete that first sentence -- there are obvious counter-examples (ray tracing / movie rendering, search engines, memoization, dynamic programming).
- SimonPStevens 8y agoI just don't think this is true. A very common tradeoff we make is to cache the results of time consuming calculations in memory, or even cache raw data in memory to avoid database calls. Both of these techniques increase memory usage, but improve performance.
- Narishma 8y agoThat depends on how expensive those calculations are relative to memory access. CPUs are very fast at doing a ton of math but very slow at reading or writing to random memory.
- SimonPStevens 8y agoYes, of course, but my point wasn't that if you cache all results your software will be faster. My point is just that it is possible to write code that consumes more memory, and runs faster under some circumstances, which refutes the ops claim that all software that uses more memory is slower.
- outworlder 8y ago> A concept a High Performance Computing professor told me once: A program which is memory intensive must be slower then one which needs little memory -- just because load/write operations from the CPU take time. Hi, there's this guy named 'cache' that wants to speak with you.
- AlisdairO 8y agoIf they're algorithmically the same, that's true, otherwise not. Caching computations takes space, but can drastically speed up runtime performance.
- CyberDildonics 8y agoICQ was much faster on a 150mhz pentium than slack is on a modern computer today.
- dagw 8y agoA program which is memory intensive must be slower then one which needs little memory -- just because load/write operations from the CPU take time. Not if the alternative to reading/writing from RAM is reading writing from disk. One piece of data processing software I used to use had its roots in the early 80s and was very memory efficient. It achieved this by rewriting the input data to disk in a clever way and the reading and writing just the parts it need. I could process gigs of data using only a couple of hundred MBs of RAM. A different, more modern, program I also used would slurp in as much data as it could fit in RAM and then just go from there. It would happily use 30 of the 32 GB or RAM I had every time it ran, but it was also 1-2 orders of magnitude faster.