111–120 of 259 posts
Earlier quoted context omitted.
Python supports types! https://www.mypy-lang.org/
This seems a bit like saying "JavaScript supports types!" because of typescript.
Earlier quoted context omitted.
Although true, it doesn't mean they can't improve its performance. Working with threads is a pain in Python. If you want to spawn +10-20 threads in a process, it can quickly become way slower than running a single thread. Removing the GIL and refactoring some of the core will unlock levels of concurrency that are currently not feasible with Python. And that's a great deal, in my opinion. Well worth the trouble they'r…
Working with threads is a pain regardless of which language you use. Some might say: "Use Go!" Alas: https://songlh.github.io/paper/go-study.pdf After a couple decades of coding, I can say that threading is better if it's tightly controlled, limited to usages of tight parallelism of an algorithm. Where it doesn't work is in a generic worker pool where you need to put mutex locks around everything -- and then prod ran…
Earlier quoted context omitted.
Mojo should be viewed as an attack on the Python ecosystem due to it being a superset. It can consume Python, but it itself is not Python. Taichi is really underrated, it works across all platforms (including Metal), has tons of examples and the code is easy to write. And lastly, it integrates with the ecosystem and doesn't displace it. https://github.com/taichi-dev great demo reel of what Taichi can do, https://www.…
Never heard of taichi before looks promising. Do you know any shop that uses it for prod code?
https://www.researchgate.net/publication/337118128_Taichi_a_...
Earlier quoted context omitted.
There's no need to pretend Python has virtues which it lacks. It's not a fast language. It's fast enough for many purposes, sure, but it isn't fast, and this work is unlikely to change that. Fast er , sure, and that's great.
This is entirely fair, and I wish I'd been a little less grumpy in my initial reply (I assign some blame to just getting over an illness). Thank you for the gentle correction! That said - I think it's fair to be irritated by people who write Python off as entirely useless because it is not _the fastest_ language. As you rightly say - it's fast enough for many purposes. It does bother me to see Python immediately coun…
First I read the news of tranched bread, and now this?! What a time! I was a bit disheartened when the Unladen Swallow project [1] fizzled out. Great to see Python back on the core optimization track. [1] https://en.wikipedia.org/wiki/CPython#Unladen_Swallow
Earlier quoted context omitted.
Managing processes is more annoying than threads, though. Incl. data passing and so forth.
The "ray" library makes running python code on multi core and clusters very easy.
Earlier quoted context omitted.
You seem to be implying that there is something inherently slow to Python. What? This topic is an example: a detail of one particular implementation, since GIL is definitely not inherent to the language. Just the usual worry about looseness of types?
CPython is slow. That's not really something you can dispute. It is a non-optimizing bytecode interpreter and it makes no use of JIT compilation. JavaScript with V8 or any other modern JIT JS engine runs circles around it. Go, Java, and C# are an order of magnitude faster but they have type systems that make optimizing compilation much easier. There's no language-inherent reason why Python can't be at least as fast a…
Earlier quoted context omitted.
Although true, it doesn't mean they can't improve its performance. Working with threads is a pain in Python. If you want to spawn +10-20 threads in a process, it can quickly become way slower than running a single thread. Removing the GIL and refactoring some of the core will unlock levels of concurrency that are currently not feasible with Python. And that's a great deal, in my opinion. Well worth the trouble they'r…
Working with threads is a pain regardless of which language you use. Some might say: "Use Go!" Alas: https://songlh.github.io/paper/go-study.pdf After a couple decades of coding, I can say that threading is better if it's tightly controlled, limited to usages of tight parallelism of an algorithm. Where it doesn't work is in a generic worker pool where you need to put mutex locks around everything -- and then prod ran…
This may be a case of violent agreement, but there are a few clear cases where multithreading is easily viable. The best case is some sort of parallel-for construct, even if you include parallel reductions, although there may need to be some smarts around how to do the reduction (e.g., different methods for reduce-within-thread versus reduce-across-thread). You can extend this to heterogeneous parallel computations, a general, structured fork-join form of concurrency. But in both cases, you essentially have to forbid inter-thread communication between the fork and the join parameters. There's another case you might be able to make work, where you have a thread act as an internal server that runs all requests to completion before attempting to take on more work.
What the paper you link to is pointing out, in short, is that message passing doesn't necessarily free you from the burden of shared-mutable-state-is-bad concurrency. The underlying problem is largely that communication between different threads (or even tasks within a thread) can only safely occur at a limited number of safe slots, and any communication outside of that is risky, be it an atomic RMW access, a mutex lock, or waiting on a message in a channel.
Earlier quoted context omitted.
Python is just the more popular language. Julia array manipulation is mostly better (better syntax, better integration, larger standard library) or as good as python. Julia is also dynamically typed. It is also faster than Python, except for the jit issues.
> It is also faster than Python, except for the jit issues. I was intrigued by Julia a while ago, but didn't have time to properly learn it. So just out of curiosity: what's the issues with jit and Julia ?