Hi,
I have some data what the Async Detour usually
costs. I just compared with another Java Prolog
that didn't do the thread thingy.
Reported measurement with the async Java Prolog:
JDK 24: 50 ms (using Threads, not yet VirtualThreads)
New additional measurement with an alternative Java Prolog:
JDK 24: 30 ms (no Threads)
But already the using Threads version is quite optimized,
it basically reuse its own thread and uses a mutex
somewhere, so it doesn't really create a new secondary
thread, unless a new task is spawn. Creating a 2nd thread
is silly if task have their own thread. This is the
main potential of virtual threads in upcoming Java,
just run tasks inside virtual threads.
Bye
P.S.: But I should measure with more files, since
the 50 ms and 30 ms are quite small. Also I am using a
warm run, so the files and their meta information is already
cached in operating system memory. I am trying to only
measure the async overhead, but maybe Python doesn't trust
the operating system memory, and calls some disk
sync somewhere. I don't know. I don't open and close the
files, and don't call some disk syncing. Only reading
stats to get mtime and doing some comparisons.
Hi,
I tested this one:
Python 3.11.11 (0253c85bf5f8, Feb 26 2025, 10:43:25)
[PyPy 7.3.19 with MSC v.1941 64 bit (AMD64)] on win32
I didn't test yet this one, because it is usually slower:
ython 3.14.0b2 (tags/v3.14.0b2:12d3f88, May 26 2025, 13:55:44)
[MSC v.1943 64 bit (AMD64)] on win32
Bye
Mild Shock schrieb:
Hi,
I have some data what the Async Detour usually
costs. I just compared with another Java Prolog
that didn't do the thread thingy.
Reported measurement with the async Java Prolog:
JDK 24: 50 ms (using Threads, not yet VirtualThreads)
New additional measurement with an alternative Java Prolog:
JDK 24: 30 ms (no Threads)
But already the using Threads version is quite optimized,
it basically reuse its own thread and uses a mutex
somewhere, so it doesn't really create a new secondary
thread, unless a new task is spawn. Creating a 2nd thread
is silly if task have their own thread. This is the
main potential of virtual threads in upcoming Java,
just run tasks inside virtual threads.
Bye
P.S.: But I should measure with more files, since
the 50 ms and 30 ms are quite small. Also I am using a
warm run, so the files and their meta information is already
cached in operating system memory. I am trying to only
measure the async overhead, but maybe Python doesn't trust
the operating system memory, and calls some disk
sync somewhere. I don't know. I don't open and close the
files, and don't call some disk syncing. Only reading
stats to get mtime and doing some comparisons.
Sysop: | Tetrazocine |
---|---|
Location: | Melbourne, VIC, Australia |
Users: | 9 |
Nodes: | 8 (0 / 8) |
Uptime: | 120:14:59 |
Calls: | 161 |
Files: | 21,502 |
Messages: | 78,887 |