▲ 112 ▼ Free-threaded CPython is ready to experiment with! (labs.quansight.org) submitted 2 years ago by mox@lemmy.sdf.org to c/programming@programming.dev 36 comments fedilink hide all child comments
[–] FizzyOrange@programming.dev 1 point 2 years ago (2 children) numpy Numpy is written in C. Numba Numba is interesting... But a) it can already do multithreading so this change makes little difference, and b) it's still not going to be as fast as C++ (obviously we don't count the GPU backend). permalink fedilink source parent hideshow 4 child comments replies: [–] HyperCube@kbin.run 1 point 2 years ago (1 child) Numpy is written in C. So you get the best of both worlds then: the speed of C and the ease of use of Python. permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 3 points 2 years ago Sure but that's not relevant to the current discussion. The point is that removing the GIL doesn't affect Numpy because Numpy is written in C. permalink fedilink source parent [–] Womble@lemmy.world -2 points 2 years ago* (last edited 2 years ago) (1 child) Numpy is written in C. Python is written in C too, what's your point? I've seen this argument a few times and I find it bizarre that "easily able to incorporate highly optimised Fortran and C numerical routines" is somehow portrayed as a point against python. Numpy is a defacto extension to the python standard that adds first class support for single type multi-dimensional arrays and functions for working on them. It is implemented in a mixture of python and c (about 60% python according to github) , interfaces with python's c-api and links in specialist libraries for operations. You could write the same statement for parts of the python std-lib, is that also not python? Its hard to not understate just how much simpler development is in numpy compared to c++, in this example here the new python version was less than 50 lines and was developed in an afternoon, the c++ version was closing in on 1000 lines over 6 files. permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 3 points 2 years ago (1 child) Python is written in C too, what’s your point? The point is that eliminating the GIL mainly benefits pure Python code. Numpy is already multithreaded. I think you may have forgotten what we're talking about. the new python version was less than 50 lines and was developed in an afternoon, the c++ version was closing in on 1000 lines over 6 files. That's a bit suss too tbh. Did the C++ version use an existing library like Eigen too or did they implement everything from scratch? permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@lemmy.world 1 point 2 years ago* (last edited 2 years ago) I was responding to your general statement that python is slow and so there is no point in making it faster, I agree that removing the GIL wont do much to improve the execution speed for programs making heavy use of numpy or things calling outside it. That’s a bit suss too tbh. Did the C++ version use an existing library like Eigen too or did they implement everything from scratch? It was written entirely from scratch which is kind of my point, a well writen python program can outperform a naive c implementation and is vastly simpler to create. If you have the expertise and are willing to put in the effort you likely can squeze that extra bit of performance out by dropping to a lower level language, but for certain workloads you can get good performance out of python if you know what you are doing so calling it extremely slow and saying you have to move to another language if you care about performance is missleading. permalink fedilink source parent
[–] HyperCube@kbin.run 1 point 2 years ago (1 child) Numpy is written in C. So you get the best of both worlds then: the speed of C and the ease of use of Python. permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 3 points 2 years ago Sure but that's not relevant to the current discussion. The point is that removing the GIL doesn't affect Numpy because Numpy is written in C. permalink fedilink source parent
[–] FizzyOrange@programming.dev 3 points 2 years ago Sure but that's not relevant to the current discussion. The point is that removing the GIL doesn't affect Numpy because Numpy is written in C. permalink fedilink source parent
[–] Womble@lemmy.world -2 points 2 years ago* (last edited 2 years ago) (1 child) Numpy is written in C. Python is written in C too, what's your point? I've seen this argument a few times and I find it bizarre that "easily able to incorporate highly optimised Fortran and C numerical routines" is somehow portrayed as a point against python. Numpy is a defacto extension to the python standard that adds first class support for single type multi-dimensional arrays and functions for working on them. It is implemented in a mixture of python and c (about 60% python according to github) , interfaces with python's c-api and links in specialist libraries for operations. You could write the same statement for parts of the python std-lib, is that also not python? Its hard to not understate just how much simpler development is in numpy compared to c++, in this example here the new python version was less than 50 lines and was developed in an afternoon, the c++ version was closing in on 1000 lines over 6 files. permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 3 points 2 years ago (1 child) Python is written in C too, what’s your point? The point is that eliminating the GIL mainly benefits pure Python code. Numpy is already multithreaded. I think you may have forgotten what we're talking about. the new python version was less than 50 lines and was developed in an afternoon, the c++ version was closing in on 1000 lines over 6 files. That's a bit suss too tbh. Did the C++ version use an existing library like Eigen too or did they implement everything from scratch? permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@lemmy.world 1 point 2 years ago* (last edited 2 years ago) I was responding to your general statement that python is slow and so there is no point in making it faster, I agree that removing the GIL wont do much to improve the execution speed for programs making heavy use of numpy or things calling outside it. That’s a bit suss too tbh. Did the C++ version use an existing library like Eigen too or did they implement everything from scratch? It was written entirely from scratch which is kind of my point, a well writen python program can outperform a naive c implementation and is vastly simpler to create. If you have the expertise and are willing to put in the effort you likely can squeze that extra bit of performance out by dropping to a lower level language, but for certain workloads you can get good performance out of python if you know what you are doing so calling it extremely slow and saying you have to move to another language if you care about performance is missleading. permalink fedilink source parent
[–] FizzyOrange@programming.dev 3 points 2 years ago (1 child) Python is written in C too, what’s your point? The point is that eliminating the GIL mainly benefits pure Python code. Numpy is already multithreaded. I think you may have forgotten what we're talking about. the new python version was less than 50 lines and was developed in an afternoon, the c++ version was closing in on 1000 lines over 6 files. That's a bit suss too tbh. Did the C++ version use an existing library like Eigen too or did they implement everything from scratch? permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@lemmy.world 1 point 2 years ago* (last edited 2 years ago) I was responding to your general statement that python is slow and so there is no point in making it faster, I agree that removing the GIL wont do much to improve the execution speed for programs making heavy use of numpy or things calling outside it. That’s a bit suss too tbh. Did the C++ version use an existing library like Eigen too or did they implement everything from scratch? It was written entirely from scratch which is kind of my point, a well writen python program can outperform a naive c implementation and is vastly simpler to create. If you have the expertise and are willing to put in the effort you likely can squeze that extra bit of performance out by dropping to a lower level language, but for certain workloads you can get good performance out of python if you know what you are doing so calling it extremely slow and saying you have to move to another language if you care about performance is missleading. permalink fedilink source parent
[–] Womble@lemmy.world 1 point 2 years ago* (last edited 2 years ago) I was responding to your general statement that python is slow and so there is no point in making it faster, I agree that removing the GIL wont do much to improve the execution speed for programs making heavy use of numpy or things calling outside it. That’s a bit suss too tbh. Did the C++ version use an existing library like Eigen too or did they implement everything from scratch? It was written entirely from scratch which is kind of my point, a well writen python program can outperform a naive c implementation and is vastly simpler to create. If you have the expertise and are willing to put in the effort you likely can squeze that extra bit of performance out by dropping to a lower level language, but for certain workloads you can get good performance out of python if you know what you are doing so calling it extremely slow and saying you have to move to another language if you care about performance is missleading. permalink fedilink source parent