5 ms·

So, I know Ruby is not faster than python, and Java is not faster than C++, and so on. But I've been programming for... 15ish years now, professionally for alm

So, I know Ruby is not faster than python, and Java is not faster than C++, and so on. But I've been programming for... 15ish years now, professionally for almost 7, and I've yet to be unable to make a program go "fast enough" regardless of the programming language or runtime it's in. And I've had to do some honestly kinda stupid stuff like doing a bunch of CPU-intensive work in python. And I don't think I'm like, any kind of whiz. I don't know all the deep C/C++/jvm compiler magicks (I honestly find that sort of thing kind of tiresome). I've just found that between multiprocessing (like via xargs -P) and multiprocessing (the python module, or equivalent in a different language or threading in a language with real threads and no interpreter lock) and sometimes shelling out to an OS utility (written in C usually) for a bit of hard work tends to topple any problem, and usually with less damage to the code than a ton of deep magicks would inflict and with less damage to the business function than if it were written in the more-performant less-dev-productive language in the first place. I feel like I need to make a disclaimer since I know several friends who would feel MUCH chagrin at my disparagement of the deep C++ compiler magicks. It's cool, and I have immense respect for their practitioners, but I think my personal interest in programming stems from interest in logic (like the formal stuff you'd learn in a philosophy class) and how comp sci intersects that with being able to build really cool shit (in a product sense). So, you'll have to understand me when I say that it's only in extremely specific scenarios (like HFT, where I used to work, which is how I know all these chagrin'd people in the first place...) that these things tend to make a meaningful different in the product outcome.

leephillips 5y ago
Sounds like you’re saying that you’ve been able to make any language fast enough where performance is not critical, but that you realize that when it is (you mention HFT, but there is also HPC for science and engineering, a vast area), the slow languages won’t cut it. I can’t disagree, but your comment also seems like a bit of a tautology.
- naniwaduni 5y ago
  I think GP is implying a stronger point than you're making it out to, that the situations where performance is critical occur "only in extremely specific scenarios", backed by the claim that they've managed to avoid such scenarios for 7~15 years.
  - shados 5y ago
    That's kind of like saying that a backend developer has managed to avoid needing a frontend component frameworks for 20 years, so the need for such a framework is rare. It's a self fulfilling prophecy. The OP didn't pick jobs completely randomly, I assume, so they're mostly going to be working around their specific skillset, which may just not require performance critical work. If they worked at Nvidia, Intel, or Epic Games on low level engines, they could flip that around and say they haven't been in a situation where perf wasn't one of their top priorities.
shoo 5y ago
tangent: one of the more satisfying patches of my programming career was improving system stability and roughly preserving performance while removing the use of parallel processing the code grew like this: 1. some python tool is written to grab a bunch of data from a SQL DB through an ORM and do some kind of graph analysis on it. the code is annoyingly slow. 2. the problem is embarassingly parallel (tool performs analysis in terms of domain-specific paths, which can be processed independently for each region of the graph), so one of the devs chunks each problem into sub problems, distributes the work to a cluster, then aggregate the results. it's not lighting fast but a good speedup, good enough for now 3. the tool executes work in parallel but is still regarded by the business and the dev team as kind of slow. later on, another dev has time to do some profiling, sees the SQL queries generated are fairly daft and are failing to exploit ways to efficiently search the data, figures out some different queries. the tool is now running pretty fast. 4. there's an unrelated priority to uplift security. TLS is applied to the job queuing system used by the tool to execute work in parallel. the formerly-slow embarrassingly-parallel code is sending rather large volumes of intermediate data through the cluster, and alas, for technical reasons, when TLS is enabled the additional encryption overhead causes the queuing system to fail sometimes (it is so busy doing crypto on large messages that it delays sending heartbeats, which causes its clustered friends to infer a network partition, which causes the cluster to kick into panic-network-partition-recovery mode, which periodically breaks production and requires manual intervention to recover) 5. what's the fix? remember that we fixed the queries in step 3, meaning the original partial speedup from processing all the work in parallel is no longer required, so we delete all the parallel-chunking code to invert step 2, and the resulting system is fast enough when run sequentially, without using the queue to aggregate large intermediate results
shados 5y ago
> and I've yet to be unable to make a program go "fast enough" regardless of the programming language or runtime it's in. That's because you won't even attempt to do things that that can't run that fast, because you know it won't work, from experience. Let's take an example unrelated to programming languages (but easier to relate maybe?). Git branches. Git branches are fast to create and delete, so how do they get used? People create them all the time, for a million reasons. Remember SVN, or god forbid CVS, or even SourceSafe? You wouldn't create a branch for shits and giggles for those, because it was slow. You only did it when you had a good reason. Fast branches changed the way we even thought about how to use source control systems. So let's go back to programming languages. Let's take JavaScript for an easy target. I've built real time image processing that happens on mouse over at 60 frames per second even on old android devices. But when all we had was older versions of internet explorer? I wouldn't even attempt it. The same holds true for any environment, any kind of databases (regular transactional vs column stores) and yeah, C++ vs Python. People are rebuilding much of the JS toolchain in rust, purely for performance reasons. Because it's never fast enough. On the server, you could save money by using cheaper AWS instances if it was faster. And so on and so forth.
- AlotOfReading 5y ago
  I like to compare program efficiency to fuel-efficient engines. Most people could get along just fine with a 1950s clunker that gets 10mpg. They might even tell everyone they don't want to upgrade and lose the ability to fix it with nothing more than duct tape and a wrench. There are still clear advantages to all the extra complexity and cost in an efficient engine though.
- turtlebits 5y ago
  It's not necessarily that a developer won't attempt it, not all specialities of computing require it. I am in my field because it interests me, not because I can't or wont try other things.
- kaba0 5y ago
  I don’t know, both of your examples seem to be about data structures/algorithms used. I don’t think any of them would be significantly more performant given a reimplementation of the same thing in a different language.
yjftsjthsd-h 5y ago
> and Java is not faster than C++ I feel obligated to be That Guy who points out that for some programs, JIT performance makes this surprisingly untrue, although it sounds like you might be the kind of dev who can beat the JIT:) https://stackoverflow.com/questions/4516778/when-is-java-faster-than-c-or-when-is-jit-faster-then-precompiled#4528285 https://stackoverflow.com/questions/4516778/when-is-java-fas...
- Shorel 5y ago
  Java new operator leaves C++ new operator biting the dust. But then you allocate C++ objects in the stack, and that's a couple of orders of magnitude faster. It really comes down to if you can use the stack, or you have to use the heap.
  - snovv_crash 5y ago
    In C++ with a thread-local allocator or a memory pool you can effectively skip the global allocator (or at least amortize it to 0). C++ gives you the tools to fix these kinds of bottlenecks if you need to, even if it is added complexity.
    - moonchild 5y ago
      Yes, and you can similarly preallocate memory in java (though you will be unable to do type punning). Java gets used in high-frequency trading which has very tight latency and overall performance requirements, to great effect.
      - snovv_crash 5y ago
        Writing a pool in Java doesn't necessarily give you memory locality guarantees though, making you much more sensitive to cache:data size ratios. In Java you end up rewriting your algorithms as AoS instead of SoA just so that you can work with cache-aware layouts of primitives.
  - nonameiguess 5y ago
jjav 5y ago
> I've yet to be unable to make a program go "fast enough" regardless of the programming language or runtime it's in. On "fast enough": Performance matters to latency and throughput but also resource consumption and thus cost. Ok maybe you haven't worked on anything where measurements like latency and throughput matter. But surely you've worked on something where cost matters? Whether it's paying for additional hardware or VMs or increased memory requirements or more runtime minutes for "serverless" hosting, slower code always costs more to run. If traffic is super low maybe it's the difference between $0.10 and $1.00 so nobody cares. But grow that company and suddenly it's $10K vs. $100K, the CFO is now paying attention. A couple startups ago I redesigned a system so it was able to handle ~50x the user load per server (no special magic, just JVM tuning, DB tuning, removing some of the worst-offender slow code). The ops team had been in the process of ramping up server count and instead they ended up removing 30+% of the servers assigned to it. From a customer perspective it wasn't faster (it actually was faster, but not in a way any customer would've noticed) but higher performance code sure saved us a lot of money.
bryanrasmussen 5y ago
> and I've yet to be unable to make a program go "fast enough" ok but in certain problem domains it's sort of difficult to figure out what fast enough means, for example if you have a site and when there are problems you spin up another server - the code is running fast enough because you just need to spin up another server on the other hand if the code could be improved so that you didn't need to handle the problem with using extra servers...

leephillips 5y ago

Sounds like you’re saying that you’ve been able to make any language fast enough where performance is not critical, but that you realize that when it is (you mention HFT, but there is also HPC for science and engineering, a vast area), the slow languages won’t cut it. I can’t disagree, but your comment also seems like a bit of a tautology.

naniwaduni 5y ago
I think GP is implying a stronger point than you're making it out to, that the situations where performance is critical occur "only in extremely specific scenarios", backed by the claim that they've managed to avoid such scenarios for 7~15 years.
- shados 5y ago
  That's kind of like saying that a backend developer has managed to avoid needing a frontend component frameworks for 20 years, so the need for such a framework is rare. It's a self fulfilling prophecy. The OP didn't pick jobs completely randomly, I assume, so they're mostly going to be working around their specific skillset, which may just not require performance critical work. If they worked at Nvidia, Intel, or Epic Games on low level engines, they could flip that around and say they haven't been in a situation where perf wasn't one of their top priorities.

shoo 5y ago

tangent: one of the more satisfying patches of my programming career was improving system stability and roughly preserving performance while removing the use of parallel processing the code grew like this: 1. some python tool is written to grab a bunch of data from a SQL DB through an ORM and do some kind of graph analysis on it. the code is annoyingly slow. 2. the problem is embarassingly parallel (tool performs analysis in terms of domain-specific paths, which can be processed independently for each region of the graph), so one of the devs chunks each problem into sub problems, distributes the work to a cluster, then aggregate the results. it's not lighting fast but a good speedup, good enough for now 3. the tool executes work in parallel but is still regarded by the business and the dev team as kind of slow. later on, another dev has time to do some profiling, sees the SQL queries generated are fairly daft and are failing to exploit ways to efficiently search the data, figures out some different queries. the tool is now running pretty fast. 4. there's an unrelated priority to uplift security. TLS is applied to the job queuing system used by the tool to execute work in parallel. the formerly-slow embarrassingly-parallel code is sending rather large volumes of intermediate data through the cluster, and alas, for technical reasons, when TLS is enabled the additional encryption overhead causes the queuing system to fail sometimes (it is so busy doing crypto on large messages that it delays sending heartbeats, which causes its clustered friends to infer a network partition, which causes the cluster to kick into panic-network-partition-recovery mode, which periodically breaks production and requires manual intervention to recover) 5. what's the fix? remember that we fixed the queries in step 3, meaning the original partial speedup from processing all the work in parallel is no longer required, so we delete all the parallel-chunking code to invert step 2, and the resulting system is fast enough when run sequentially, without using the queue to aggregate large intermediate results

shados 5y ago

> and I've yet to be unable to make a program go "fast enough" regardless of the programming language or runtime it's in. That's because you won't even attempt to do things that that can't run that fast, because you know it won't work, from experience. Let's take an example unrelated to programming languages (but easier to relate maybe?). Git branches. Git branches are fast to create and delete, so how do they get used? People create them all the time, for a million reasons. Remember SVN, or god forbid CVS, or even SourceSafe? You wouldn't create a branch for shits and giggles for those, because it was slow. You only did it when you had a good reason. Fast branches changed the way we even thought about how to use source control systems. So let's go back to programming languages. Let's take JavaScript for an easy target. I've built real time image processing that happens on mouse over at 60 frames per second even on old android devices. But when all we had was older versions of internet explorer? I wouldn't even attempt it. The same holds true for any environment, any kind of databases (regular transactional vs column stores) and yeah, C++ vs Python. People are rebuilding much of the JS toolchain in rust, purely for performance reasons. Because it's never fast enough. On the server, you could save money by using cheaper AWS instances if it was faster. And so on and so forth.

AlotOfReading 5y ago
I like to compare program efficiency to fuel-efficient engines. Most people could get along just fine with a 1950s clunker that gets 10mpg. They might even tell everyone they don't want to upgrade and lose the ability to fix it with nothing more than duct tape and a wrench. There are still clear advantages to all the extra complexity and cost in an efficient engine though.
turtlebits 5y ago
It's not necessarily that a developer won't attempt it, not all specialities of computing require it. I am in my field because it interests me, not because I can't or wont try other things.
kaba0 5y ago
I don’t know, both of your examples seem to be about data structures/algorithms used. I don’t think any of them would be significantly more performant given a reimplementation of the same thing in a different language.

yjftsjthsd-h 5y ago

> and Java is not faster than C++ I feel obligated to be That Guy who points out that for some programs, JIT performance makes this surprisingly untrue, although it sounds like you might be the kind of dev who can beat the JIT:) https://stackoverflow.com/questions/4516778/when-is-java-faster-than-c-or-when-is-jit-faster-then-precompiled#4528285 https://stackoverflow.com/questions/4516778/when-is-java-fas...

Shorel 5y ago
Java new operator leaves C++ new operator biting the dust. But then you allocate C++ objects in the stack, and that's a couple of orders of magnitude faster. It really comes down to if you can use the stack, or you have to use the heap.
- snovv_crash 5y ago
  In C++ with a thread-local allocator or a memory pool you can effectively skip the global allocator (or at least amortize it to 0). C++ gives you the tools to fix these kinds of bottlenecks if you need to, even if it is added complexity.
  - moonchild 5y ago
    Yes, and you can similarly preallocate memory in java (though you will be unable to do type punning). Java gets used in high-frequency trading which has very tight latency and overall performance requirements, to great effect.
    - snovv_crash 5y ago
      Writing a pool in Java doesn't necessarily give you memory locality guarantees though, making you much more sensitive to cache:data size ratios. In Java you end up rewriting your algorithms as AoS instead of SoA just so that you can work with cache-aware layouts of primitives.
- nonameiguess 5y ago

jjav 5y ago

> I've yet to be unable to make a program go "fast enough" regardless of the programming language or runtime it's in. On "fast enough": Performance matters to latency and throughput but also resource consumption and thus cost. Ok maybe you haven't worked on anything where measurements like latency and throughput matter. But surely you've worked on something where cost matters? Whether it's paying for additional hardware or VMs or increased memory requirements or more runtime minutes for "serverless" hosting, slower code always costs more to run. If traffic is super low maybe it's the difference between $0.10 and $1.00 so nobody cares. But grow that company and suddenly it's $10K vs. $100K, the CFO is now paying attention. A couple startups ago I redesigned a system so it was able to handle ~50x the user load per server (no special magic, just JVM tuning, DB tuning, removing some of the worst-offender slow code). The ops team had been in the process of ramping up server count and instead they ended up removing 30+% of the servers assigned to it. From a customer perspective it wasn't faster (it actually was faster, but not in a way any customer would've noticed) but higher performance code sure saved us a lot of money.

bryanrasmussen 5y ago

> and I've yet to be unable to make a program go "fast enough" ok but in certain problem domains it's sort of difficult to figure out what fast enough means, for example if you have a site and when there are problems you spin up another server - the code is running fast enough because you just need to spin up another server on the other hand if the code could be improved so that you didn't need to handle the problem with using extra servers...