5 ms·

I'm honestly skeptical if > Make it work, then make it right, then make it fast. Applies to core language choice, I used to hear a lot about rewriting interpr

by lumost 4y ago

I'm honestly skeptical if > Make it work, then make it right, then make it fast. Applies to core language choice, I used to hear a lot about rewriting interpreted langs to something faster... but the reality is that a team that's just spent 1 year making an app in python aren't going to pivot to writing Java, Go, or Rust one day. The new team isn't going to be building something new and exciting, they are going to be on a tight timeline to deliver a port of something which already exists.

secondcoming 4y ago
Maybe, I mainly use python as a more sophisticated bash script, or to prototype something I'll port to a performant language later.
edflsafoiewq 4y ago
IME fast software doesn't actually use this "waterfall" model. There needs to be feedback from performance considerations into semantics.
welder 4y ago
Just did this, rewrote a deployed cli from Python[1] to Go[2]. It delivered on all the expectations. Less CPU & RAM usage, less dependence on system stuff like openssl, more diverse platform support. [1] https://github.com/wakatime/legacy-python-cli https://github.com/wakatime/legacy-python-cli [2] https://github.com/wakatime/wakatime-cli https://github.com/wakatime/wakatime-cli
ChrisMarshallNY 4y ago
In my case, the choice is made for me (I write Apple native, so Swift, it is...). I have found that his advice on using profilers was very important. I thought I knew where it would be slow, but the profiler usually stuck its tongue out at me and laughed. When I ran a C++ shop, optimization was a black art. Things like keeping code and pipelines in low-level caches could have 100X impact on performance, so we would do things like optimize to avoid breaking cache. This often resulted in things like copying and pasting lines of code to run sequentially, instead of in a loop, or as a subroutine/method. It's difficult. There's usually some "low-hanging fruit" that will give awesome speedups, then, it gets difficult.
- mrfox321 4y ago
  Do your tricks still apply to modern c++ compilers?
  - moonchild 4y ago
    I cannot speak for c++, but I recently rewrote an optimised c routine in assembly. A 2-4x speedup obtained. I might have gotten partway with careful tuning of the source, the way the parent suggests, but I could have not gotten all the way.
  - favorited 4y ago
    [Not GP] Modern optimizers are great, but writing cache-efficient code is still up to the programmer.
  - jandrewrogers 4y ago
    Modern C++ compilers are mixed bag when it comes to optimization, brilliant in some areas and inexplicably obtuse in others requiring the programmer to be quite explicit. This has improved significantly with time but I am still sometimes surprised by the code the compiler has difficulty optimizing, or which are only recognized if written in very narrow ways. As a practical matter, compilers have a limited ability to reason over large areas of code in the way a programmer can but even very local optimizations are sometimes missed. This is why it is frequently helpful to look at the code generated by the C++ compiler. It gives you insight into the kinds of optimizations the compiler can see and which ones it can't, so you can focus on the ones it struggles with. This knowledge becomes out-of-date on the scale of years, so I periodically re-check what I think I know about what the compiler can optimize. For some things, like vectorization, the compiler's optimizer almost never produces a good result for non-trivial code and you'll have to do it yourself.
    - orangepurple 4y ago
      I recommend using Godbolt (https://godbolt.org/ https://godbolt.org/) to view the assembly output of your compiled language (C++, etc)
colechristensen 4y ago
I don't know, I've been places where select pieces of infrastructure were being rewritten from language X to Y for performance reasons, and it seemed to be going just fine. It wasn't "we're rewriting everything now" but finding performance bottlenecks and fixing them by rewriting pieces in the new language. It works if you have lots of things communicating over APIs.
ayberk 4y ago
This definitely doesn't apply to developer tools in general (and sometimes also to infrastructure). Anyone who had the "pleasure" of using Amazon's internal tools can talk about how "Make it work ASAP" attitude has worked out for their internal tooling :) LPT anyone?
deleted 4y ago
[deleted]
anothernewdude 4y ago
My team literally do this all the time. Python for everything, Rust for the places where it doesn't keep up.
dilap 4y ago
You have to be thinking about speed from the beginning. You don't actually have to make it fast, but you have to be designing w/ an eye towards eventual speed. Otherwise you end up w/ a mess that can be made faster, but never fast. At least that's been my experience.

by lumost 4y ago

secondcoming 4y ago

Maybe, I mainly use python as a more sophisticated bash script, or to prototype something I'll port to a performant language later.

edflsafoiewq 4y ago

IME fast software doesn't actually use this "waterfall" model. There needs to be feedback from performance considerations into semantics.

welder 4y ago

Just did this, rewrote a deployed cli from Python[1] to Go[2]. It delivered on all the expectations. Less CPU & RAM usage, less dependence on system stuff like openssl, more diverse platform support. [1] https://github.com/wakatime/legacy-python-cli https://github.com/wakatime/legacy-python-cli [2] https://github.com/wakatime/wakatime-cli https://github.com/wakatime/wakatime-cli

ChrisMarshallNY 4y ago

In my case, the choice is made for me (I write Apple native, so Swift, it is...). I have found that his advice on using profilers was very important. I thought I knew where it would be slow, but the profiler usually stuck its tongue out at me and laughed. When I ran a C++ shop, optimization was a black art. Things like keeping code and pipelines in low-level caches could have 100X impact on performance, so we would do things like optimize to avoid breaking cache. This often resulted in things like copying and pasting lines of code to run sequentially, instead of in a loop, or as a subroutine/method. It's difficult. There's usually some "low-hanging fruit" that will give awesome speedups, then, it gets difficult.

mrfox321 4y ago
Do your tricks still apply to modern c++ compilers?
- moonchild 4y ago
  I cannot speak for c++, but I recently rewrote an optimised c routine in assembly. A 2-4x speedup obtained. I might have gotten partway with careful tuning of the source, the way the parent suggests, but I could have not gotten all the way.
- favorited 4y ago
  [Not GP] Modern optimizers are great, but writing cache-efficient code is still up to the programmer.
- jandrewrogers 4y ago
  Modern C++ compilers are mixed bag when it comes to optimization, brilliant in some areas and inexplicably obtuse in others requiring the programmer to be quite explicit. This has improved significantly with time but I am still sometimes surprised by the code the compiler has difficulty optimizing, or which are only recognized if written in very narrow ways. As a practical matter, compilers have a limited ability to reason over large areas of code in the way a programmer can but even very local optimizations are sometimes missed. This is why it is frequently helpful to look at the code generated by the C++ compiler. It gives you insight into the kinds of optimizations the compiler can see and which ones it can't, so you can focus on the ones it struggles with. This knowledge becomes out-of-date on the scale of years, so I periodically re-check what I think I know about what the compiler can optimize. For some things, like vectorization, the compiler's optimizer almost never produces a good result for non-trivial code and you'll have to do it yourself.
  - orangepurple 4y ago
    I recommend using Godbolt (https://godbolt.org/ https://godbolt.org/) to view the assembly output of your compiled language (C++, etc)

colechristensen 4y ago

I don't know, I've been places where select pieces of infrastructure were being rewritten from language X to Y for performance reasons, and it seemed to be going just fine. It wasn't "we're rewriting everything now" but finding performance bottlenecks and fixing them by rewriting pieces in the new language. It works if you have lots of things communicating over APIs.

ayberk 4y ago

This definitely doesn't apply to developer tools in general (and sometimes also to infrastructure). Anyone who had the "pleasure" of using Amazon's internal tools can talk about how "Make it work ASAP" attitude has worked out for their internal tooling :) LPT anyone?

deleted 4y ago

[deleted]

anothernewdude 4y ago

My team literally do this all the time. Python for everything, Rust for the places where it doesn't keep up.

dilap 4y ago

You have to be thinking about speed from the beginning. You don't actually have to make it fast, but you have to be designing w/ an eye towards eventual speed. Otherwise you end up w/ a mess that can be made faster, but never fast. At least that's been my experience.