| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 26 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 17:31:40 |
| Calls: | 484 |
| Calls today: | 1 |
| Files: | 1,074 |
| Messages: | 98,219 |
Looking at that Java spec, a “virtual thread” is just another name for “stackful coroutine”. Because that’s what you get when you take away implicit thread preemption and substitute explicit preemption instead.
Short answer: no.
<https://discuss.python.org/t/add-virtual-threads-to-python/91403>
Firstly, anybody appealing to Java as an example of how to design a programming language should immediately be sending your bullshit detector into the yellow zone.
Secondly, the link to a critique of JavaScript that dates from 2015, from before the language acquired its async/await constructs, should be another warning sign.
Looking at that Java spec, a “virtual thread” is just another name for “stackful coroutine”. Because that’s what you get when you take away implicit thread preemption and substitute explicit preemption instead.
The continuation concept is useful in its own right. Why not concentrate
on implementing that as a new primitive instead?
Try using Erlang a little, It has preemptive lightweight processes and
it is great. Much better than async/await imho.
Try using Erlang a little, It has preemptive lightweight processes and
it is great. Much better than async/await imho.
Those are called “threads”. Python already has those, and the ongoing “noGIL” project will make them even more useful.
Erlang's lightweight processes are called "processes" rather than
"threads" since they don't give the appearance of having shared memory.
They communicate by passing data through channels. From the
application's perspective, that is always done by copying the data,
although the VM sometimes optimizes away the copying behind the scenes.
Python has OS threads but they are way more expensive than Erlang
processes.
Remember, Python’s threads are OS threads. If you’re thinking “expensive”,
you must be assuming “Microsoft Windows”.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Remember, Python’s threads are OS threads. If you’re thinking
“expensive”, you must be assuming “Microsoft Windows”.
Let's see how CPython holds up with a million OS threads running.
Let's see how CPython holds up with a million OS threads running.Linux can already run hundreds of thousands of processes/threads
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Let's see how CPython holds up with a million OS threads running.
Linux can already run hundreds of thousands of processes/threads
To misquote Austin Powers, "one MILLLLLION threads". Here Erlang does
it in less than 1GB of memory:
https://hauleth.dev/post/beam-process-memory-usage/
In other words, you do not want to copy stuff between processes if you can help it.
I'd be interested in seeing some benchmarks of multi-threaded Python
beating Erlang, if you have any to show.
Concerning virtual threads the only problem
with Java I have is, that JDK 17 doesn't have them.
And some linux distributions are stuck with JDK 17.
Otherwise its not an idea that belongs solely
to Java, I think golang pioniered them with their
goroutines. I am planning to use them more heavily
when they become more widely available, and I don't
see any principle objection that Python wouldn't
have them as well. It would make async I/O based
on async waithing for a thread maybe more lightweight.
But this would be only important if you have a high
number of tasks.
Lawrence D'Oliveiro schrieb:
Short answer: no.
<https://discuss.python.org/t/add-virtual-threads-to-python/91403>
Firstly, anybody appealing to Java as an example of how to design a
programming language should immediately be sending your bullshit detector
into the yellow zone.
Secondly, the link to a critique of JavaScript that dates from 2015, from
before the language acquired its async/await constructs, should be
another
warning sign.
Looking at that Java spec, a “virtual thread” is just another name for >> “stackful coroutine”. Because that’s what you get when you take away >> implicit thread preemption and substitute explicit preemption instead.
The continuation concept is useful in its own right. Why not concentrate
on implementing that as a new primitive instead?
node.js: 10 ms (usual Promises and stuff)
JDK 24: 50 ms (using Threads, not yet VirtualThreads)
pypy: 2000 ms
Hi,
async I/O in Python is extremly disappointing
and an annoying bottleneck.
The problem is async I/O via threads is currently
extremly slow. I use a custom async I/O file property
predicate. It doesn't need to be async for file
system access. But by some historical circumstances
I made it async since the same file property routine
might also do a http HEAD request. But what I was
testing and comparing was a simple file system access
inside a wrapped thread, that is async awaited.
Such a thread is called for a couple of directory
entries to check a directory tree whether updates
are need. Here some measurement doing this simple
involving some little async I/O:
node.js: 10 ms (usual Promises and stuff)
JDK 24: 50 ms (using Threads, not yet VirtualThreads)
pypy: 2000 ms
So currently PyPy is 200x times slower than node.js
when it comes to async I/O. No files were read or
written in the test case, only "mtime" was read,
via this Python line:
stats = await asyncio.to_thread(os.stat, url)
Bye
Mild Shock schrieb:
Concerning virtual threads the only problem
with Java I have is, that JDK 17 doesn't have them.
And some linux distributions are stuck with JDK 17.
Otherwise its not an idea that belongs solely
to Java, I think golang pioniered them with their
goroutines. I am planning to use them more heavily
when they become more widely available, and I don't
see any principle objection that Python wouldn't
have them as well. It would make async I/O based
on async waithing for a thread maybe more lightweight.
But this would be only important if you have a high
number of tasks.
Lawrence D'Oliveiro schrieb:
Short answer: no.
<https://discuss.python.org/t/add-virtual-threads-to-python/91403>
Firstly, anybody appealing to Java as an example of how to design a
programming language should immediately be sending your bullshit
detector
into the yellow zone.
Secondly, the link to a critique of JavaScript that dates from 2015,
from
before the language acquired its async/await constructs, should be
another
warning sign.
Looking at that Java spec, a “virtual thread” is just another name for >>> “stackful coroutine”. Because that’s what you get when you take away >>> implicit thread preemption and substitute explicit preemption instead.
The continuation concept is useful in its own right. Why not concentrate >>> on implementing that as a new primitive instead?