5 ms·

This is actually very, very sane. I've been a professional developer for 25 years, and in the old days we used to -- or, rather, had to -- make use of a lot of

by pron 8y ago

This is actually very, very sane. I've been a professional developer for 25 years, and in the old days we used to -- or, rather, had to -- make use of a lot of crazy hacks to get what we wanted, in terms of performance and RAM footprint, from slow, RAM-limited machines. This resulted both in brittle code (which wasn't so bad because the programs had to be small) and in increased development time. These days, you can increase the performance of your code by writing well-optimized code, using a better compiler (but there's a limit to that), getting more CPUs (but there's a limit to that, too, due terms of hardware support, programming style and Amdahl's law) and getting more RAM. By far the most expensive option is writing hand-optimized code, and the cheapest, least limited resource (except for special cases of constrained environments) is RAM. Every MB of RAM spent on making your code faster while still keeping development costs low is a MB well-spent. Of course, nothing here should be taken to the extreme.

specialist 8y ago
I'm really struggling with this. Most of my professional career, I've optimized my time. My novel strategy has always been "do less work" (aka a month of coding can save a week of design). 80% of a project is maintenance, right? Mitigating that means clear code, good docs, safety net of tests, etc. Is that 80% still true? I've heard, but cannot yet validate, that code now only lives 3 years. I just can't believe how much code we're all creating. Over the weekend, I rewrote some incomprehensible goo which took months to create. A module all our services use. A real pain point. My rewrite is 1/6th the size. Was the rewrite worth it? I honestly can't say.
- BenoitP 8y ago
  > I've heard, but cannot yet validate, that code now only lives 3 years. That would be the rate at which the Hello World's and the front-end pieces get replaced. Back-end or entreprise code is very different in my experience. Most enterprise internal apps actually live for much much longer that that. These are seen as cost centers and never get the necessary cash to be properly refactored. They are usually riddled with copious amounts of lava flow anti-patterns [1]; and outlive several times over the users, the developers, the management, and the founders/CEOs. If the hardware dies, they get put as-is on a VM that emulates the old hardware. Development is incremental and grinds slowly down, tending to the asymptotic ratio of changing business needs w.r.t. the amount of archeology required. [1] https://en.wikipedia.org/wiki/Lava_flow_(programming) https://en.wikipedia.org/wiki/Lava_flow_(programming)
mpweiher 8y ago
I can see how you can make that argument, it makes a lot of sense on the surface. However, it has the slight problem of not actually being true. First, accessing RAM is (apart from I/O) the most expensive part of your program these days. "The reality today is very different: computation is essentially free, because it happens “in the cracks” between data fetch and data store; on a clocked processor, there is little difference in energy consumption between performing an arithmetic op- eration and peforming a no-op." -- Andrew Black, Object-oriented programming: some history, and challenges for the next fifty years So making your code more RAM intensive is very unlikely to make it faster, and much more likely to make it slower. Second: yes, there is a relationship between time-saving technologies and RAM use, but it is mostly coincidental, not causal. My NeXT cube ( 16MB RAM, 400MB HD) had a very productive development environment, and earlier Smalltalk systems were arguably more productive, with even less resource use. We're slowly groping towards fast feedback loops and loosely coupled components (and often times away from, hence the slowness), and sometimes we pick up some goodness almost as if by accident. They don't need lots of RAM, the Alto had 128KB.
- pron 8y ago
  > However, it has the slight problem of not actually being true. The slight problem of your explanation showing that you do not actually understand the issue makes this unprovoked snide remark not only unnecessary but also embarrassing. > First, accessing RAM is (apart from I/O) the most expensive part of your program these days. That is absolutely true but has nothing to do with my argument, as the cost of access is not dependent (at least not much, and NUMA aside) on how much RAM you're using (once you exceed cache sizes etc.). A thousand cache misses cost the same whether your heap is 100 MB or 1 TB. In fact, using more RAM can make it easier to access RAM less, and so can make your application significantly faster precisely because access is expensive. For example, suppose a common operation in your program is using the average of a set of numbers (that doesn't change often). Computing that average would require a large number of RAM operations (depending on the size of the set). On the other hand, computing that value once and caching it, would need more RAM but would access it less. Another example: some modern GCs (like ZGC) have worst-case pauses that are independent of the size of the heap, but the rate of collection increases the less memory you have. Therefore, increasing your heap would only reduce the amount of time spent in GC (because it reduces RAM access by increasing RAM usage). > Second: yes, there is a relationship between time-saving technologies and RAM use, but it is mostly coincidental, not causal. It's very hard to learn from old examples because they operated in a very different environment under very different constraints and requirements (also, RAM constraints affected Smalltalk's ability to cache JITted code, and made it less efficient). But in order to make my argument less controversial, let me put it this way: if you can pay for productivity/performance with RAM you're making a good deal.

by pron 8y ago

specialist 8y ago

I'm really struggling with this. Most of my professional career, I've optimized my time. My novel strategy has always been "do less work" (aka a month of coding can save a week of design). 80% of a project is maintenance, right? Mitigating that means clear code, good docs, safety net of tests, etc. Is that 80% still true? I've heard, but cannot yet validate, that code now only lives 3 years. I just can't believe how much code we're all creating. Over the weekend, I rewrote some incomprehensible goo which took months to create. A module all our services use. A real pain point. My rewrite is 1/6th the size. Was the rewrite worth it? I honestly can't say.

BenoitP 8y ago
> I've heard, but cannot yet validate, that code now only lives 3 years. That would be the rate at which the Hello World's and the front-end pieces get replaced. Back-end or entreprise code is very different in my experience. Most enterprise internal apps actually live for much much longer that that. These are seen as cost centers and never get the necessary cash to be properly refactored. They are usually riddled with copious amounts of lava flow anti-patterns [1]; and outlive several times over the users, the developers, the management, and the founders/CEOs. If the hardware dies, they get put as-is on a VM that emulates the old hardware. Development is incremental and grinds slowly down, tending to the asymptotic ratio of changing business needs w.r.t. the amount of archeology required. [1] https://en.wikipedia.org/wiki/Lava_flow_(programming) https://en.wikipedia.org/wiki/Lava_flow_(programming)

mpweiher 8y ago

I can see how you can make that argument, it makes a lot of sense on the surface. However, it has the slight problem of not actually being true. First, accessing RAM is (apart from I/O) the most expensive part of your program these days. "The reality today is very different: computation is essentially free, because it happens “in the cracks” between data fetch and data store; on a clocked processor, there is little difference in energy consumption between performing an arithmetic op- eration and peforming a no-op." -- Andrew Black, Object-oriented programming: some history, and challenges for the next fifty years So making your code more RAM intensive is very unlikely to make it faster, and much more likely to make it slower. Second: yes, there is a relationship between time-saving technologies and RAM use, but it is mostly coincidental, not causal. My NeXT cube ( 16MB RAM, 400MB HD) had a very productive development environment, and earlier Smalltalk systems were arguably more productive, with even less resource use. We're slowly groping towards fast feedback loops and loosely coupled components (and often times away from, hence the slowness), and sometimes we pick up some goodness almost as if by accident. They don't need lots of RAM, the Alto had 128KB.

pron 8y ago
> However, it has the slight problem of not actually being true. The slight problem of your explanation showing that you do not actually understand the issue makes this unprovoked snide remark not only unnecessary but also embarrassing. > First, accessing RAM is (apart from I/O) the most expensive part of your program these days. That is absolutely true but has nothing to do with my argument, as the cost of access is not dependent (at least not much, and NUMA aside) on how much RAM you're using (once you exceed cache sizes etc.). A thousand cache misses cost the same whether your heap is 100 MB or 1 TB. In fact, using more RAM can make it easier to access RAM less, and so can make your application significantly faster precisely because access is expensive. For example, suppose a common operation in your program is using the average of a set of numbers (that doesn't change often). Computing that average would require a large number of RAM operations (depending on the size of the set). On the other hand, computing that value once and caching it, would need more RAM but would access it less. Another example: some modern GCs (like ZGC) have worst-case pauses that are independent of the size of the heap, but the rate of collection increases the less memory you have. Therefore, increasing your heap would only reduce the amount of time spent in GC (because it reduces RAM access by increasing RAM usage). > Second: yes, there is a relationship between time-saving technologies and RAM use, but it is mostly coincidental, not causal. It's very hard to learn from old examples because they operated in a very different environment under very different constraints and requirements (also, RAM constraints affected Smalltalk's ability to cache JITted code, and made it less efficient). But in order to make my argument less controversial, let me put it this way: if you can pay for productivity/performance with RAM you're making a good deal.