3 ms·

It’s an interesting debate ( money aside ). In the past 15 years, at least to my eyes, one of the most important changes in soft eng culture has been the now sy

It’s an interesting debate ( money aside ). In the past 15 years, at least to my eyes, one of the most important changes in soft eng culture has been the now systematic search for correctness. Systematic, organized, large scale Testing is one side of the coin, but the real value , and significantly more important change to me is guarantees/proofs : static analysis, stronger type systems, etc. So type annotations in Python, typescript, rust instead of c++, etc. Tools as well : golang race detector, infer, coverity, pvs studio, code peer (Ada)/spark, compcert, etc. In this particular case, I understand that removing the Gil would create potential new risks ( but provide better performance) and although tooling is mentioned, it’s not officially part of the plan, so it feels like a regression of some sorts.

klysm 3y ago
It might be worth it though because somehow python had ended up being the lingua Franca in a many applications where performance matters a great deal (ML, scientific applications, etc). I don’t think the performance benefits for something deployed at such a large scale should be understated.
- local_crmdgeon 3y ago
  Indeed and to add - the environmental impact of Python’s speed is nontrivial and growing
  - klysm 3y ago
    Although you are almost certainly correct, I’m curious if there is a case where faster doesn’t mean more power efficient I.e. more concurrency but more power overall
    - H8crilA 3y ago
      Concurrent execution is ~always less power efficient than serial execution. I have no idea what the parent comments are talking about. For almost any work X with time to run on a single core T it will run on two cores in time larger than T/2, and on three cores in time larger than T/3, ... This is due to synchronization overhead (e.g. networking, locks, delays) and also often due to shared resources getting saturated (e.g. VRAM on a GPU). That is unless in the serial execution you still have to pay for some resources that are unutilized.
      - tornato7 3y ago
        However, if you're running a computer with a 16-core CPU, power usage doesn't scale linearly with cores. There's a lot of overhead, especially if you're talking about a laptop/desktop with display, HID, etc.
IshKebab 3y ago
I don't think that has really been a change in the past 15 years. Well, maybe there was just a lull in people caring about correctness and robustness... But it's not like before 15 years ago everyone was using dynamically typed languages and static analysers didn't exist. I guess you could say the world went through a dynamically typed loosy goosy phase and then realised that wasn't so great. I think one thing that actually has changed is that SMT solvers have massively advanced in the last 20 years to the point that formal verification is practical. Ish anyway. It still seems to require a PhD to do software formal verification. Hardware formal verification is easy though.

klysm 3y ago

It might be worth it though because somehow python had ended up being the lingua Franca in a many applications where performance matters a great deal (ML, scientific applications, etc). I don’t think the performance benefits for something deployed at such a large scale should be understated.

local_crmdgeon 3y ago
Indeed and to add - the environmental impact of Python’s speed is nontrivial and growing
- klysm 3y ago
  Although you are almost certainly correct, I’m curious if there is a case where faster doesn’t mean more power efficient I.e. more concurrency but more power overall
  - H8crilA 3y ago
    Concurrent execution is ~always less power efficient than serial execution. I have no idea what the parent comments are talking about. For almost any work X with time to run on a single core T it will run on two cores in time larger than T/2, and on three cores in time larger than T/3, ... This is due to synchronization overhead (e.g. networking, locks, delays) and also often due to shared resources getting saturated (e.g. VRAM on a GPU). That is unless in the serial execution you still have to pay for some resources that are unutilized.
    - tornato7 3y ago
      However, if you're running a computer with a 16-core CPU, power usage doesn't scale linearly with cores. There's a lot of overhead, especially if you're talking about a laptop/desktop with display, HID, etc.

IshKebab 3y ago

I don't think that has really been a change in the past 15 years. Well, maybe there was just a lull in people caring about correctness and robustness... But it's not like before 15 years ago everyone was using dynamically typed languages and static analysers didn't exist. I guess you could say the world went through a dynamically typed loosy goosy phase and then realised that wasn't so great. I think one thing that actually has changed is that SMT solvers have massively advanced in the last 20 years to the point that formal verification is practical. Ish anyway. It still seems to require a PhD to do software formal verification. Hardware formal verification is easy though.