Why is Python so slow?

Why is Python so slow?
Will it ever be optimized enough to be on par with JS?
Will it ever get rid of GIL?
Will it ever be truly ready for parallel computing without high cost of multiprocessing (i.e. spinning up a whole new python instance + ipc costs)?

These are genuine questions. I like Python and I'm worried about its future.

Attached: js-python.png (191x908, 36K)

Other urls found in this thread:

quora.com/How-fast-is-Python-3-x-compared-to-2-7
twitter.com/AnonBabble

bump

Why does python need to be fast?

Fuck yourself brainlet. Python3 is where it all went to shit

just don't get fooled by some dump benchmarks

Because taking x30 more time to complete the same task is not an advantage.

python is a language that's designed to make everything really easy and versatile. it has nothing to do with speed. the modern paradigm is to call fast algorithms from within python or to prototype with python and then deploy with fast languages. making python fast makes no sense and probably isn't possible.
if another language finally usurps python it will be one that's equally easy but is also fast.

>if another language finally usurps python it will be one that's equally easy but is also fast.
JS.

lol

Why not? It is faster and arguably it takes the same amount of time to write JS code.

I assume CPython for the following questions:
>Why is Python so slow?
Because it doesn't have a billion-dollar corporation with enough manpower to end slavery, rare earth mines and all misery in the world powering it. Unlike the following:
>Will it ever be optimized enough to be on par with JS?
Not as fast as V8, no.
>Will it ever get rid of GIL?
Removing the GIL limits performance even more, as far as I recall because a lot of the core needs to be made thread-safe.
>Will it ever be truly ready for parallel computing without high cost of multiprocessing (i.e. spinning up a whole new python instance + ipc costs)?
It already is for I/O-bound code where the GIL is released. For CPU-bound code, the answer is no.

because you're not using numpy, numba or any of the other shit you should be using if speed is an issue

bump

If you want speed wrap it with C which is what Node does for you.

Or use C wrapped libraries like numpy which someone already said.

>why is my native code faster than my interpreted code

very good thread op

*Go

This. It’s plenty fast if you aren’t retarded

Why do I have to do extra work to make python faster if JS just works and it is already fast enough?

>it just works when running it in a C runtime env
Okay, so write JS then. No one cares?

Python devs have convinced themselves that Python is "fast enough" and have chosen to ignore the real problems of their language. Meanwhile Python is getting outdated fast and this thread is yet another proof of how python people try to bury their heads in the sand.

Pic related is 3.8 changelog. They don't even try to address a single issue in their language. All they care about is syntactic sugar. Python is stuck in the early 2000s and cannot compete in the modern age. Single core language in 2020, lul.

Attached: 38.png (853x705, 95K)

because it's interpreted language

So is PHP

Attached: php.png (203x896, 31K)

It's a scripting language. There's fast libraries available for data if you need them, which is essentially the only niche of the language at this point. It's also trivial to wrap python in C if you need to, which is all the JS frameworks are anyway.

No one learns one language and calls it a day. It's literally a non-issue. Just use what works easiest for whatever you're doing.

Dumbass, that isn't pre-compiled python. Which is what every server would be running. Not compiling it literally every time it's ran.

I like Go, but having worked in both Go and Python they aren't really interchangeable. Syntactically they're both expressive and readable, but under the hood they're too different.
Python is a quick and dirty "play with your code" interpreted language where Go is a no-frills compiled language for infastructure.
Pic related if one wants to learn Golang.

Attached: 516R4ZoMqBL._AC_SY400_.jpg (323x400, 20K)

Use pypy and stop complaining.

>inb4 tensorflow support or some shit
If you're using tensorflow then python isn't your bottleneck.

>tensorflow
pypy doesn't even support some of the standard libraries. It is literally DOA.

Still has the GIL problem.

The GIL is released on demand for I/O and data processing by non-standard libs. You're a dumb monkey.

why not? 30x of like a few 100 milliseconds is hardly an issue in every single domain python is useful in. I use python a lot solely because it's something i can rely on that isn't compiled.

JS, although easy and fast, isn't as powerfully dynamic as python and can be difficult to wield compared to python in some cases.

>hurr durr GIL isn't a problem
Autistic shill. Even pypy devs acknowledge that GIL in fact IS a problem.

it isn't you fucking moron like it isn't a problem in most JS engines. having threads and shared memory in a scripting language overwhelmingly increases the level of difficulty of its use and the costs of spawning children processes and throwing messages isn't all that much. GIL only matters for non I/O based concurrency in python anyhow.

speed of computing the mandlebrot in python with numpy and numba is at par with C
Speaking with experience.

Must have been a few years since you checked compatibility.
A while ago they changed their cpython api compatibility magic and pretty much everything works now.

python doesn't have a GIL. Python is just a set of constructs whose interpreter can be implemented in any language.
C implementation (CPython) has GIL
Java implementation (Jython) and IronPython don't

>Even pypy devs acknowledge that GIL in fact IS a problem
because most of them are just shallow programmers who are on the bandwagon of "hating GIL" just for the sake of sounding more obscure and "prestigious".
GIL has far more merits than demerits.

Attached: 1553644608249.jpg (1200x773, 336K)

>there are now 64 Cores 128 Threads CPUs
>GIL effectively limits computations to 1 core per instance
>GIL has far more merits than demerits
The absolute state of python programmers. You are literally moving in the opposite way.

>The speed of c is comparable to c.
Interdasting

>python doesn't have a GIL. Python is just a set of constructs whose interpreter can be implemented in any language.
Not sure communism, huh?

When people say 'python', they mean cpython, not pypy or jython or ironpython.

all pythonlets became gotards

actually kill yourself. JS is a slow, bloated, insecure as fuck language, and as far as I see it, is a cancer to web dev. But it's easy so retards like you come along, code a few lines of JS, and now you think you're hot shit.
You're actually dumb as fuck and if you think because you are in tech, you are smart, you are dead wrong faggot. JS is a cancer on this world just like your shit opinion, and I hope they both die within my lifetime to watch.

quora.com/How-fast-is-Python-3-x-compared-to-2-7

python3 is complete shit..

Cope harder

>Will it ever be optimized enough to be on par with JS?
No
>Will it ever get rid of GIL?
Maybe, but that won't make it fast. Just somewhat better at multithreaded operations.
>Will it ever be truly ready for parallel computing without high cost of multiprocessing
Even if the GIL thing is fixed, python is a fundamentally bad choice for anything computing-constrained. Python is good for organizing a bunch of blocking operations (making web requests, reading files, etc) and orchestrating actually efficient utilities to do some real workload. If you're feeling the cost of multiprocessing in python, you should be using another language anyway.

The only relevant post in this shit-stained thread full of coping pythonlets

> slow and bloated
> its async
> v8 is c++

Try harder

This is one of the most retarded posts I've seen in a while

>>> def start():
... first = time.time()
... for n in range(1000000):
... print(n)
... last = time.time()
... print("time: " + str(last-first))
...

i do that in console python 3.x is getting an average of 6.999214172363281
while python2.7 give me 4.77178788185
why is it still getting support fuck that version

most of C code isn't thread safe
not introducing GIL would make C support for python terrible. Python is so popular only because of how well it emulates C libraries (all of it). This is performance-universality trade off.
Just use multiprocessing or some other language if you're so dissatisfied with the GIL. Stop spurring non-sense without knowing the purpose of a language.
its merits are incomprehensible by "performance" bigots like you

>without knowing the purpose of a language.
Python is a high-level _general-purpose_ programming language. Quote from python.org

and? your point being?

My point is you don't have to figure out some specific purpose for the language. The purpose is already stated by the devs. I'd rather trust the python devs than some random schizo Jow Forumstard.

bump

dead

Making Python fast means reimplementing the entire standard library in Python in some language that a JIT can easily optimize across. And seeing how fucking enormous Python is that's pretty difficult. Cython sort of works around this by compiling everything to C so the compiler can work its magic.

because writing Python is faster. are you starting to get it?

which scripting language is making Python outdated?

Lua

lmaoooo

If you cared you'd just write performance sensitive shit in C FFI.
I know you people don't because your shit is always slow. But that's the solution for any scripting language.

Isn't there shit you can use to "compile" python to C? Seems like that'd be a happy medium.