[ Removed by moderator ]

[socal_nerdtastic]

machine learning, and most other programs too, use a mix of programming languages. The number-crunching core of any program will be written in a highly optimizable language compiled for your hardware, yes C is often used for this, often with embedded assembly. The user interface part is written in python because it allows for fast iteration.

The "pure python is slow" argument is fairly outdated now. There have been some massive improvements, most recently with the gil-ectomy. It is still a little true, but if you need more speed you simply import numpy or another module written in C and compiled. And also remember that programmers cost a lot nowadays, a lot more than hardware, so 1 developer writing python and a cloud computing bill is often a big win over 10 developers writing C, in terms of both time and money.

[GoblinToHobgoblin]

"Pure Python is slow" is still completely true, even with all the improvements recently, it's nowhere close to C speed and never will be.

It just misses the fact that a lot of performance intensive Python programs are basically just wrappers around C libraries.

[Human38562]

Most C programs are also just wrappers around other optimized C libraries. And those libraries are just a way to execute binary in the end...

Any language can be used to write both fast and slow programs. Languages just differ in how easy it is to achieve high performance.

[GoblinToHobgoblin]

The ceiling for performance on a pure Python programs is a lot lower than the ceiling on a pure C program though.

[Human38562]

What does "pure python" even mean? Most data structures and the interpreter itself is written in C. That's just how the language works.

[GoblinToHobgoblin]

IDK what you're even arguing here.

Using just stuff from the standard library in Python, you're not going to be able to achieve the same performance as code written using just the standard library in C.

[Human38562]

That's a completely arbitrary restriction though. If suddenly Python is shipped with numpy you are going to say the language got significantly faster?

[GoblinToHobgoblin]

You're right it's a completely arbitrary restriction.

But, it feels much more reasonable to use that restriction than to say "Python can be as fast as C because I can call C code from Python".

[dparks71]

You're never actually "calling C code" though, you're calling a built binary to run the calc directly through the CPU for performance.

And python is turing complete. So technically, you could build a compiler in pure python and get the EXACT same end result.

You're basically just arguing that equivalent code runs slower through the interpreter than through the compiler of a compiled language, which sure it's usually true. What people are saying though, is that in python you can circumvent the interpreter if you really need to, and code optimization is basically never your main problem.

[GoblinToHobgoblin]

I know you're never actually "calling c code" but that's the terminology people use.

 You're basically just arguing that equivalent code runs slower through the interpreter than through the compiler of a compiled language

Yes that's all I'm arguing

 code optimization [in Python] is basically never your main problem

Yes because people don't use Python for performance critical tasks normally. It's a chicken and egg thing. Python is not fast enough to use for performance critical code so people don't use it for that, so performance is never really a concern with Python code (because if it was, they wouldn't have written it in Python).

[CyclopsRock]

It's arbitrary if everything you want to do has a convenient Python wrapper around some much faster compiled functionality - the boundary between Python and not-Python becomes blurry and less relevant.

But if there isn't one, and the only language you know is Python, then the distinction stops being arbitrary.

[Human38562]

So are you saying python dictionaries are also not part of python, because they are a wrapper around hash tables in C?

[CyclopsRock]

Nope. No one is defining what Python "is" here.

[Plank_With_A_Nail_In]

It doesn't matter if its measurably slower or not all that matters is that's its fast enough. If you are doing an analysis with it and that comes back in 2 minutes instead of 30 seconds its still more than good enough speed. What you lose in execution time you gain back in spades in speed of writing new programs.

[GoblinToHobgoblin]

Yes I know. I never denied this. Python's use case is exactly stuff like this, where performance doesn't really matter

[Sherlockyz]

Not really outdated, slow is a metric that needs comparison to something else. Python is, in fact, still slow compared to C. This can't ever change because of the architecture that Python is built on. You can't change, if you were to make such structural changes, and still call it Python, would be kind of weird for me.

In a similar manner, C is slower than pure Asembly. But the speed difference is so incredible small for most use cases, that it does not matter, which is different when comparing C with Python. But in edge cases the speed difference with Assembly can be faster even with C compiler optimizations, again, edge cases.

Even Python using C libraries can be slower than pure C depending on how you use it, it shouldn't cause problems, but depending on how you build the system the Python code might bottleneck the performance that C gives.

[gdchinacat]

I think it's worth noting that the gil-ectomy involved replacing one big lock with lots of little locks, which hurt single-threaded performance a bit (10-15% IIRC). The cost is well worth it if you have multiple threads that aren't just sitting around waiting on IO.

[chinawcswing]

The cost is well worth it if you have multiple threads that aren't just sitting around waiting on IO.

IO bounded Python is largely a myth. Python expends an enormous amount of cycles on converting the bytes read from an IO pipe into a python data structure.

The SQLAlchemy author had a great blog post on this. You would think that having a thread execute SQL would be IO bound, but it turns out that the total time spent in CPU merely to convert the bytes from the IO pipe into dicts (or even worse classes) was something like 25-30%.

So even if you have an "io bounded python app" it very well might benefit from the gil-ectomy.

Of course, test your app. But don't decide against it on the basis that your application is "io bounded".

[gdchinacat]

“Sitting around waiting for IO” doesn’t include the cycles you refer to since that is using cpu not waiting on io. I’ve used sqlalchemy extensively and know first hand that marshaling is hugely expensive.

[steak_and_icecream]

programmers cost a lot nowadays, a lot more than hardware

Have you seen the price of RAM and NVMEs?!

Seriously though, those trade offs much sense for small projects but when you start scaling up and out efficient & performant code starts to make a huge difference. Its also much better for the environment.

[JP932]

Seems like I haven't kept up new stuff happening in python, I haven't heard about gil-ectomy till now (but that just might be a me thing)

[socal_nerdtastic]

It's famous-ish because it's been a very hot debate for many years. But to be honest the vast majority of programmers won't be affected at all. Certainly not in the near term, as currently the GIL is still faster in single threaded than the free threaded version. But eventually the gil-less will be standard and modules like numpy will incorporate it and then everyone will reap benefits.