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:


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.


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 

Reply via email to