Async Python is not faster

When I talk about async await I'm talking about everything that encompasses supporting that syntax. This includes the I/O event loop.

So really we're in agreement. You're talking about reimplementing python specific things to make it more performant, and that is exactly another way of saying that the problem is python specific.

> And the major language most machine learning researchers use is Python.

Read again what I wrote. Even the model itself is optimized. The fact that it is written in Python or in any DSL is irrelevant.

> I used to think that too before I spent years doing functional programming.

I have done functional programming in many languages, ranging from lambda calculus itself to OCaml to Haskell, including inside and outside academia. It does not change anything I have said.

Perhaps you spent way too many years in high-level languages that you have started believing magical properties about their compilers.

> prided myself on being able to implement things like highly-optimized numerical code with templates.

Optimizing numerical code has little to do with code monomorphization.

It does sound like you were abusing C++ thinking you were "optimizing" code without actually having a clue.

Like in the previous point, it seemed you attributed magical properties to C++ compilers back then, and now you do the same with high-level ones.

> It actually took a few years before my code in Lisp, Scheme, JavaScript, and Python stopped being structured like C++.

How do you even manage write code in Lisp etc. "like C++"? What does that even mean?

> You putting "Python" and "Java" in the same sentence shows this isn't a process you've gone through yet. Java has roughly the same limitations as C and C++.

Pure nonsense. Java is nowhere close to C or C++.

> Here's a challenge for you.

I would use Mathematica or Julia for that. Not Scheme, not C++. Particularly since you already declared the last 30% of performance is irrelevant.

You are again mixing up domins. You are picking a high-level domain and then complaining a low-level tool does not fit nicely. That has nothing to do with the discussion and we could apply that flawed logic to back any statement we want.

> Perhaps you spent way too many years in high-level languages that you have started believing magical properties about their compilers.

> It does sound like you were abusing C++ thinking you were "optimizing" code without actually having a clue.

> Like in the previous point, it seemed you attributed magical properties to C++ compilers back then, and now you do the same with high-level ones.

I think at this point, I'm checking out. You're making a lot of statements and assumptions about who I am, what my background is, what I know, and so on. I neither have the time nor the inclination to debunk them. You don't know me.

When you make it personal and start insulting people, that's a good sign you've lost the technical argument. Technical errors in your posts highlight that too.

If you do want to have a little bit of fun, though, you should look up the template-based linear algebra libraries of the late nineties and early 00's. They were pretty clever, and for a while, were leading in the benchmarks. They would generate code, at compile time, optimized to the size of your vectors and matrixes, unroll loops, and similar. They seem pretty well-aligned to your background. I think you'll appreciate them.

Hi - you will need to pip install the requirements into a virtualenv. Then set $PWPWORKERS (eg to 1 to start with) and run serve-gunicorn-flask.sh. That will get you a gunicorn instance up and running. From them on you'll need to set up nginx, pgbouncer and postgres. I used unix sockets between all of these but using TCP/IP is fine. The data generation script is checked in, as is the schema.

Before you start you should know that Tudor M (see a PR on the project) experimented with changing the query patterns (to three queries, but not a count(*)). It doesn't change matters and the basic reason for that is that nothing has changed - simply having more blocking or non-blocking IO is irrelevant to throughput - except that the more yields you have the more problematic your response times are going to be under load.

Except the problem here is that those tests were bottlenecked by IO. Whether you're testing C++, pypy, libuv, or whatever it doesn't matter.

All that matters is the concurrency model because that application he's running is barely doing anything else except IO and anything outside of IO becomes negligible because after enough requests, those sync worker processes will all be spending the majority of their time blocked by an IO request.

The basic essence of the original claim is that sync is not necessarily better than async for all cases of high IO tasks. I bring up node as a counter example because that async model IS Faster for THIS same case. And bringing up node is 100% relevant because IO is the bottleneck, so it doesn't really matter how much faster node is executing as IO should be taking most of the time.

Clearly and logically the async concurrency model is better for these types of tasks so IF tests indicate otherwise for PYTHON then there's something up with python specifically.

You're right, we are in disagreement. I didn't realize you completely failed to understand what's going on and felt the need to do an apples to apples comparison when such a comparison is not Needed at all.