Hacker News Reader

Hacker News

Comment by typon | Hacker News Reader

Full thread

typon

I blame Python and Javascript. Two of the most popular languages without proper concurrency support.

View on HN

You mean parallelism ? JS has good concurrency support (event, async..)

Did it in 2005 though?

I think Python also has async / await support today.

Perhaps in 2005 we were still able to call across browser frames and abusing the one thread per frame model.

async / await isn't really concurrency. It's a mechanism for picking up the job after something else has been done (perhaps like a callback). In a way it's been an advantage of Javascript: one or two threads do all the work in a timely way without all that messy thread scheduling and context switches.

That’s concurrency without in-process parallelism.

I find the distinction far less interesting than most people. I thing it's easier to think of parallelism simply as an interesting special case of concurrency, and to think of runtimes and systems that are "concurrent" but can't run literally simultaneously, like Javascript or Python, as simply accidents of history not worth specially writing into the definitions of our terms. Every year "concurrent" code that can't be scheduled to run on multiple CPUs simultaneously is less and less interesting. And I don't anticipate any new language coming out in the future that will try to be "concurrent but can only run on one CPU", so this meaning is just going to fade into history as a particular quirk of some legacy runtimes.

No, I do not consider any runtime that can't run on multiple CPUs simultaneously to have "good" concurrency support. It would, at best, be bad concurrency support. Better than "no" support, sure, but not good in 2021. If a new language came out with that support, nobody would call it "good" support, they'd call it failing to even raise the table stakes a new language needs nowadays.

What's your definition of running simultaneously because CPython's approach to running on multiple cores is multiprocessing which works honestly fine. The tooling to do it is pretty slick where you can ignore a lot of the typical pain of IPC.

Because if "good" concurrency support means single-process multi-threaded on multiple cores running with enough locks that you can have multiple threads executing code simultaneously in a shared memory space then a lot of languages are going to fall down or punt all responsibility for doing that safely to the programmer which might as well be no support.

Shared memory spaces. Your "slick tooling" is one of the hacks I mentioned that history will forget, by the standard of "if a new language emerged that tried to call that 'concurrency' nobody would take it seriously".

I should say that "hack" here isn't necessarily a perjorative. There are reasons for communities to create and deploy those. There are plenty of cases where existing code can be leveraged to work better than it could without it, and that's the relevant standard for whether something is useful, not whether or not in a parallel universe the code could have been written in some completely different way or whether in some hypothetical sense if you could push a button and rewrite something for free you'd end up with something better. Hacks can be good, and every language will pick them up at some point as history evolves around it and some of the core assumptions a language/runtime made go out of date. But it's still a hack.

While OS process boundaries do provide some nice features, they are also in general overkill. See Erlang and Pony for some alternate riffs on the idea, and if you look at it hard enough and understand it deeply enough, even what Rust does can provide some similar benefits without raising a full OS process boundary between bits of code.

You're saying that shared memory concurrency is the future? I think you've got it completely wrong. Shared memory concurrency is the past. It was thought to be a good idea in the 80s and 90s, but we now know that it's both hard to program, and that it works poorly with highly-parallel, high-performance hardware. In the future, we'll see more and more programming systems which don't provide shared memory concurrency at all.

I believe there will always be situations (though specific) where a shared-memory concurrency model is the most efficient and performant use of available resources. For this reason alone, shared-memory concurrency will always have a place. That said, I generally agree that the isolated parallel memory model is preferable for simplicity's sake.

Shared memory space, not necessarily shared memory. I referenced Erlang & Pony after all so it's not like I'm unaware of the issues here. You don't need a full OS process boundary to separate things; it is a very crude and blunt instrument and there are much better options available. Separation is nice but paying to cross OS boundaries with every message kills performance dead. A full OS process boundary between all concurrently-running threads would be insane overkill for a Rust, Erlang or Pony program, and in practice, with best practices and the use of some tooling, even for Go, even if it is just old-fashioned shared-memory at its core.

"Memory space" is usually called "address space". And I think you're confused - context switching is expensive but there's no context switching involved when you're running in parallel across N cores. We're talking about parallelism, not concurrency.

No, we're talking about what I'm talking about. I've started the whole thread and participated all the way down to here. I also find myself wondering if you understand what we're talking about. I know what I'm saying about terminology is a bit controversial, but the nature of what existing run time systems are doing is not. They've been doing it for decades.

But I guess we'll just have to leave it there.

I have usually seen the distinction between concurrency and parallelism being drawn for precisely the opposite reason: parallelism without concurrency is a relatively commonly used niche, it is much simpler than concurrency, and it has special tools that make sense just for it.

For example, CUDA exposes a parallel programming model with low support for actual concurrency. Similarly, OpenMP is mostly useful for parallel computations that rarely need coordination. C#'s Parallel package is another example.

By contrast, concurrency often rears its ugly head even in single-threaded workflows, even ones that are part of larger multi-threaded programs.

Parallelism in JavaScript is simple using web workers. of course the tricky part as with all parallel applications is managing the complexity you create yourself. The only languages that seem to do a good job at handling this for you are challenging in other ways like Haskell and Erlang.

I don't think web workers are a good design. They are maybe simple, but lack in flexibility and capability. E.g. if I am not mistaken, you cannot control animations from a web worker. You also have to communicate with them using strings, therefore there is considerable overhead.

JavaScript and the related ecosystem in the browser lack a number of things, that are then patched over using additional complexity such as web assembly, bug handling/ feature workarounds in applications, mobile apps that you basically have to develop, because the web isn't useable/ performant enough for some stuff. Of course we have some extra experience now and it is easy to criticize in hindsight. E.g. the decision to make JavaScript less LISPy was perhaps a good decision for it's large adoption but longer term the homoiconicity could have been used for easier generation instead of e.g. stuff like WebAssembly. We also know, that stuff like Clojure(Script) is possible now. We also know, that we really want a native 64bit integer type instead of hodge-podge solutions with reduced precision of 53 bits or big decimal with worse/ complicated performance characteristics.

For the last 12 or so years, the web and related technologies became an application platform and a video delivery network with demands that rival native applications. We even use JavaScript on the server side through Node.JS. This has enabled tremendous things to happen but it is also perhaps the least stable platform to develop for. The web actively breaks some of the more complex applications that it has enabled precisely because the foundations are not solid enough. The current state of affairs is we keep piling on new and shiny APIs and technologies, that perhaps have considerable merit but we don't really fix the broken things in a way normal devs could keep up. I mean, how do you imagine to keep up, if even GMail, Google Maps, YouTube, Facebook and all its web apps, even major news sites and other applications backed by big companies still have rather obvious bugs in these products? I guess, "move fast and break things [for the later generations to fix all this mess]" it is.

What is Python missing in your eyes? Cooperative multitasking is a relatively recent thing to be in vogue again, and python has had good support for multithreading and multiprocessing since forever.

Without in-process multi-threading with OS threads, writing performant parallel code is nearly impossible. Most of the time you have to drop down to C/C++, disable the GIL and implement parallelism there.

Every time someone brings up the GIL and performance, the answer is pretty much always "use a different language for the places you need especially high performance". All this sturm and drang about Python not being performant enough is missing the point. It's not supposed to be the answer to special cases where maximum performance is required! It's a general-purpose language that is built around community and easy readability and elimination of boilerplate, and be good-enough for a vast majority of usecases. Just like any language, there are usecases where it is not appropriate. Clearly, it has succeeded given its significant reach and longevity.

Most high-level languages implement their performance critical functions at a lower level. However, languages that rely on a GIL (Python and Ruby) or isolated memory spaces (V8) have an additional hurdle that if you want a model of concurrency with many threads acting simultaneously on a single shared memory space you have to do additional work.

For Python you either have to have your library pause execution of Python bytecode and do multithreaded things on your memory space, allocate an isolated memory arena for your multithreaded work, copy data in and out of it, and then spawn non-Python threads (see PEP 554 for an IRL example of this idea with the Python interpreter itself), or copy data to another process which can do the multithreaded things.

With PEP 554 (right now using the C API) I personally have no issue with multithreaded Python since the overhead of copying memory between interpreters is fast enough for my work but it is overhead.

There is nothing about the Python language spec (as gleaned from looking at how CPython works) that forces it to be slow or not handle parallelism. In fact the addition of the massive amounts of library code and language changes to support async show that Python isn't even immune to preventing added complexity.

Also dask works pretty good all the way upto 200-250 CPU cores. It's pretty straightforward to build your code to use dask rather than numpy or pandas

Reply on news.ycombinator.com