3 ms·

In clock speed perhaps, but in instructions per cycle absolutely not (not even close). So for the vast vast majority of workloads a newer processor will be much

In clock speed perhaps, but in instructions per cycle absolutely not (not even close). So for the vast vast majority of workloads a newer processor will be much better than even an higher clocked but old (E8400 is from 2008) processor.

lumost 6y ago
Much better, but not the 2^4 or 16x improvement we would have gotten had moore's law continued as usual. I've anecdotally noticed a substantial shift from interpreted languages of the teens to statically compiled languages over the last 15 years. I wouldn't be surprised if this trend is simply due to performance. There is a ~2x perf improvement from moving to a non-gc, natively compiled language in most benchmarks - will companies 10 years from now reap a dividend from being on average 2x faster than their competitors?
- gridlockd 6y ago
  Moore's law has continued, but this increase in transistors stopped translating into commensurate increases in performance at every level. I would argue that wherever performance really matters, that is, where it is measured and where the improvement is estimated to reduce cost or increase revenue to the point where the programming effort is justified, we're already near the optimum. I don't see many fields where this is the case today but won't be tomorrow. In the past, software needed to be optimized just to run at all, but that constraint is gone forever. Consumers generally accept software that is kinda clunky and slower than it needs to be, peak performance rarely becomes the differentiator that it needs to be to justify optimization on modern hardware. Language benchmarks only give you the theoretical lower bound of runtime, but software in practice is usually much slower than that, regardless of language. For instance, it's not unusual to see some C code with unfavorable complexity, just because someone didn't bother to bring in a data structure that would've been part of the standard library of a slower language.
  - lumost 6y ago
    I think the optimal point is more ambiguous in the industry than we normally think. In the earlier part of the teens SaaS businesses in high throughput (>1k TPS) fields such as ad-tech were often created with ruby/python and related languages. From my observation these businesses hit significant friction managing costs as they scaled relative to peer companies using Java/C stacks. While it was possible to build a competing product on latency, it wasn't generally feasible to build a competing product on latency and cost given the throughput constraints. Particularly while maintaining adequate feature velocity. When I worked in such shops cost was a constant conversation during development ( for good reason ) and that conversation didn't come up nearly as often in the statically typed shops. Everyone thought they were more productive in Ruby/Python at the time. The gap between python and java is a lot bigger than java and C though, and I wouldn't be surprised if the latter optimization doesn't become worth it for a while longer.

lumost 6y ago

Much better, but not the 2^4 or 16x improvement we would have gotten had moore's law continued as usual. I've anecdotally noticed a substantial shift from interpreted languages of the teens to statically compiled languages over the last 15 years. I wouldn't be surprised if this trend is simply due to performance. There is a ~2x perf improvement from moving to a non-gc, natively compiled language in most benchmarks - will companies 10 years from now reap a dividend from being on average 2x faster than their competitors?

gridlockd 6y ago
Moore's law has continued, but this increase in transistors stopped translating into commensurate increases in performance at every level. I would argue that wherever performance really matters, that is, where it is measured and where the improvement is estimated to reduce cost or increase revenue to the point where the programming effort is justified, we're already near the optimum. I don't see many fields where this is the case today but won't be tomorrow. In the past, software needed to be optimized just to run at all, but that constraint is gone forever. Consumers generally accept software that is kinda clunky and slower than it needs to be, peak performance rarely becomes the differentiator that it needs to be to justify optimization on modern hardware. Language benchmarks only give you the theoretical lower bound of runtime, but software in practice is usually much slower than that, regardless of language. For instance, it's not unusual to see some C code with unfavorable complexity, just because someone didn't bother to bring in a data structure that would've been part of the standard library of a slower language.
- lumost 6y ago
  I think the optimal point is more ambiguous in the industry than we normally think. In the earlier part of the teens SaaS businesses in high throughput (>1k TPS) fields such as ad-tech were often created with ruby/python and related languages. From my observation these businesses hit significant friction managing costs as they scaled relative to peer companies using Java/C stacks. While it was possible to build a competing product on latency, it wasn't generally feasible to build a competing product on latency and cost given the throughput constraints. Particularly while maintaining adequate feature velocity. When I worked in such shops cost was a constant conversation during development ( for good reason ) and that conversation didn't come up nearly as often in the statically typed shops. Everyone thought they were more productive in Ruby/Python at the time. The gap between python and java is a lot bigger than java and C though, and I wouldn't be surprised if the latter optimization doesn't become worth it for a while longer.