this post was submitted on 27 Jun 2023
21 points (100.0% liked)
Python
6375 readers
74 users here now
Welcome to the Python community on the programming.dev Lemmy instance!
๐ Events
Past
November 2023
- PyCon Ireland 2023, 11-12th
- PyData Tel Aviv 2023 14th
October 2023
- PyConES Canarias 2023, 6-8th
- DjangoCon US 2023, 16-20th (!django ๐ฌ)
July 2023
- PyDelhi Meetup, 2nd
- PyCon Israel, 4-5th
- DFW Pythoneers, 6th
- Django Girls Abraka, 6-7th
- SciPy 2023 10-16th, Austin
- IndyPy, 11th
- Leipzig Python User Group, 11th
- Austin Python, 12th
- EuroPython 2023, 17-23rd
- Austin Python: Evening of Coding, 18th
- PyHEP.dev 2023 - "Python in HEP" Developer's Workshop, 25th
August 2023
- PyLadies Dublin, 15th
- EuroSciPy 2023, 14-18th
September 2023
- PyData Amsterdam, 14-16th
- PyCon UK, 22nd - 25th
๐ Python project:
- Python
- Documentation
- News & Blog
- Python Planet blog aggregator
๐ Python Community:
- #python IRC for general questions
- #python-dev IRC for CPython developers
- PySlackers Slack channel
- Python Discord server
- Python Weekly newsletters
- Mailing lists
- Forum
โจ Python Ecosystem:
๐ Fediverse
Communities
- #python on Mastodon
- c/django on programming.dev
- c/pythorhead on lemmy.dbzer0.com
Projects
- Pythรถrhead: a Python library for interacting with Lemmy
- Plemmy: a Python package for accessing the Lemmy API
- pylemmy pylemmy enables simple access to Lemmy's API with Python
- mastodon.py, a Python wrapper for the Mastodon API
Feeds
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Yes, there are a lot of assumptions, incorrect information, or at least miss-leading stuff out there. So I am always interested in learning more about easy and hard ways to make things better. In fact for most things I do, Python is fast enough, but sometimes it is not.
The things I find miss-leading about what people often say about Python are that it is not that slow, and that you can always just use a library like numpy or something similar to solve speed issues. I found both to be more or less untrue in the sense of getting C like speeds. On my code, Python was indeed slow, like 1% of C speed. The surprising thing for me was using numpy helps a lot but not as much as you think. I only got to 5 to 10% of of C speed with numpy. This is because libraries are often generically compiled and to get good speed you really have to have C code that is compiled for your specific hardware with vectorization, autoparallel, and fast math at least. So generic libraries just are not going to be that fast. Another one people push is using GPUs. That also is not really very effective unless you have a very expensive card and most notably a dedicated GPU card design just for that or an array of them. The GPU performance of my workstation is significantly less then throughput of my CPU. There are hardware limitations too that are interesting. My AMD Rizen 7 based workstation would have twice the speed if I had 4 port memory rather then two port memory which is a lot more common since fully optimized code is memory IO bound at about 1/2 the CPU throughput. This must be why AMD Rizen Threadrippers seem to use 4 port memory.
There are ways around a lot of this. For example using numba can be incredible. Similarly writing your owe C code and carefully compiling it too. The careful compile is critical. Maybe one could do the same with some stock libraries, carefully compile them. Lot of the other stuff people talk about just does not work very well in terms of speed or effort such as pypy, cython, nuitka, etc.