On 6/1/2020 4:21 PM, Bogdan Popa wrote:
George Neuner writes: > But Python's DB pool is threaded, and Python's threads are core > limited by the GIL in all the major implementations (excepting > Jython). Python's Postgres pooling does not[1] use POSIX threads under the hood to manage the connections if that's what you mean, nor is the concurrency of the Python applications based on system threads. All of the Python examples use either asyncio + fork(2) or green threads + fork(2). This includes the django example[3].
I said nothing whatsoever about POSIX. And FYI, POSIX does not imply any particular implementation - POSIX specifies only the API, and a compliant implementation may provide kernel threads, user space threads, or a combination of both.
What I did say is that Python's threads are core limited - and *that* is true. As a technical matter, Python *may* in fact start threads on different cores, but the continual need to take the GIL quickly forces every running thread in the process onto the same core.
> There are a few things Python can do faster than Racket, but the VAST > difference in performance shown in the techempower tests isn't > explained by them. Here's a benchmark that doesn't touch the DB at all, showing an even bigger difference in throughput between the two: https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=json
That one actually is expected: Racket's JSON (de)serializer is relatively slow.
What wasn't expected was Sam's results from the "plain text" test which also showed Racket much slower than Python. That does hint at a lot of overhead in the Racket framework.
I wrote the latest implementation of the Racket code for that benchmark and I considered doing things like bypassing the "standard" `dispatch/servlet' implementation to avoid the overhead of all the continuation machinery in the web server, but that felt like cheating.
To my knowledge, continuations will not be a factor unless either 1) the application is written in the #web-server language (which converts everything to CPS), or 2) the code invokes one of the send/suspend/* functions.
FWIW: I try to avoid using client facing continuations in my own web applications - for my money there are too many uncertainties connected with them.
Also the stuffer does a fair amount of work to deal with long continuation URLs.
Another area where the web server does more work than it should is in generating responses: the web server uses chunked transfer encoding for all responses; whereas all the Python web servers simply write the response directly to the socket when the length of the content is known ahead of time.
My understanding is that the port passed to response/output is the actual socket ... so you can front-end it and write directly. But that might be "cheating" under your definition.
George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/2fd131be-ca0e-eaa1-6595-d31a410d43d4%40comcast.net.
