4 ms·

Some observations: * Parallelism in Clojure is cheap Parallelism is Clojure is not cheap if you are using ordinary threads, due all machinery necessary to set

by dig1 7y ago

Some observations: * Parallelism in Clojure is cheap Parallelism is Clojure is not cheap if you are using ordinary threads, due all machinery necessary to setup and start OS thread (the same applies to Java/C(++)). If you are using core.async, you will get cheap green threads. However, parallelism in Clojure is extremely easy, especially switching between non-parallel and parallel implementations (map -> pmap or using reducers). * (Lack of) Libraries and Limitations This is common misconception between Clojure novices or someone wanting to start with Clojure. Clojure embraces Java and, using Clojure primitives, you can easily make your Java code functional and safe. Lack of ML libraries in pure Clojure just means that wrapping TensorFlow java code will require couple of more Clojure functions. For me, TensorFlow API isn't the most friendlier API out there and I have impression it is specifically designed for Python by C++ programmers. You may want to check alternative DL4J [1]. [1] https://deeplearning4j.org/ https://deeplearning4j.org/

otabdeveloper4 7y ago
> due all machinery necessary to setup and start OS thread The machinery to start an OS thread is on the order of magnitude of nanoseconds. Starting an OS thread far cheaper than printing a line to stdout, for example. OS threads are only a problem in interpreted languages, because all of them have a global interpreter lock of some sort. For compiled native languages OS threads are more efficient than green threads.
- ahartmetz 7y ago
  It takes about ten microseconds to start a thread on Linux, not nanoseconds. https://stackoverflow.com/questions/3929774/how-much-overhead-is-there-when-creating-a-thread https://stackoverflow.com/questions/3929774/how-much-overhea...
  - otabdeveloper4 7y ago
    That microbenchmark is old and quite imperfect; I'm pretty sure it's not actually measuring what it claims to measure. The point still stands. Creating threads (at least in a normal OS like a modern Linux) is really fast. E.g., when processing a huge logfile it's faster to create one short-lived thread per each line than it is to use a thread pool with the producer-consumer routine and conditional variables.
- CraigJPerry 7y ago
  OS threads means context switching which means relinquishing the cpu from user space to kernel space for a time. Green threads is pure user-space. No expensive context switch.
  - fulafel 7y ago
    Context switch is switching between processes or threads that a CPU core runs. In parallel computation it's well known how to avoid that: keep the thread count equal to hardware core/thread count. Green threads enable concurrency but not parallelism, so they are not applicable to accelerating computation. (core.async isn't actually green threads, except in ClojureScript, but its thread pool is more for working around blocking calls than exloiting parallelism).
  - otabdeveloper4 7y ago
    > OS threads means context switching which means relinquishing the cpu from user space to kernel space for a time. No. The OS will switch contexts regardless of how many threads you have. Even with zero threads the OS will be context switching between processes anyways. That's just how pre-emptive multitasking works. What you're trying to say is that threads might get starved due to imperfect scheduling; but even that is wrong - you're never going to write a better scheduler than the one in the Linux kernel. I mean that seriously. If you want a deterministic scheduling routine without unpredictable delays, then just use one of the realtime schedulers provided to you by the kernel. That's what they're there for.
    - CraigJPerry 7y ago
      > The OS will switch contexts regardless of how many threads you have With IRQs pinned (via CPU mask given to the kernel at boot time) and application process pinning, there will be no preemption of the application process. > Even with zero threads the OS will be context switching between processes anyways No, this is what pinning is explicitly for. > What you're trying to say is that threads might get starved due to imperfect scheduling No, you've misunderstood
fulafel 7y ago
With fine-grained parallelism, programs don't tend to start new threads per bits of work. Instead there are a bunch of worker threads that get work delegated to them in various ways. It's this way in parallelism libs for all languages. The Clojure example uses pmap, which also uses an existing pool of threads. (source to pmap shows that it's backed by futures: https://github.com/clojure/clojure/blob/clojure-1.10.0/src/clj/clojure/core.clj#L7012 https://github.com/clojure/clojure/blob/clojure-1.10.0/src/c... - futures are amply documented to be backed by thread pool)
deleted 7y ago
[deleted]

by dig1 7y ago

otabdeveloper4 7y ago

> due all machinery necessary to setup and start OS thread The machinery to start an OS thread is on the order of magnitude of nanoseconds. Starting an OS thread far cheaper than printing a line to stdout, for example. OS threads are only a problem in interpreted languages, because all of them have a global interpreter lock of some sort. For compiled native languages OS threads are more efficient than green threads.

ahartmetz 7y ago
It takes about ten microseconds to start a thread on Linux, not nanoseconds. https://stackoverflow.com/questions/3929774/how-much-overhead-is-there-when-creating-a-thread https://stackoverflow.com/questions/3929774/how-much-overhea...
- otabdeveloper4 7y ago
  That microbenchmark is old and quite imperfect; I'm pretty sure it's not actually measuring what it claims to measure. The point still stands. Creating threads (at least in a normal OS like a modern Linux) is really fast. E.g., when processing a huge logfile it's faster to create one short-lived thread per each line than it is to use a thread pool with the producer-consumer routine and conditional variables.
CraigJPerry 7y ago
OS threads means context switching which means relinquishing the cpu from user space to kernel space for a time. Green threads is pure user-space. No expensive context switch.
- fulafel 7y ago
  Context switch is switching between processes or threads that a CPU core runs. In parallel computation it's well known how to avoid that: keep the thread count equal to hardware core/thread count. Green threads enable concurrency but not parallelism, so they are not applicable to accelerating computation. (core.async isn't actually green threads, except in ClojureScript, but its thread pool is more for working around blocking calls than exloiting parallelism).
- otabdeveloper4 7y ago
  > OS threads means context switching which means relinquishing the cpu from user space to kernel space for a time. No. The OS will switch contexts regardless of how many threads you have. Even with zero threads the OS will be context switching between processes anyways. That's just how pre-emptive multitasking works. What you're trying to say is that threads might get starved due to imperfect scheduling; but even that is wrong - you're never going to write a better scheduler than the one in the Linux kernel. I mean that seriously. If you want a deterministic scheduling routine without unpredictable delays, then just use one of the realtime schedulers provided to you by the kernel. That's what they're there for.
  - CraigJPerry 7y ago
    > The OS will switch contexts regardless of how many threads you have With IRQs pinned (via CPU mask given to the kernel at boot time) and application process pinning, there will be no preemption of the application process. > Even with zero threads the OS will be context switching between processes anyways No, this is what pinning is explicitly for. > What you're trying to say is that threads might get starved due to imperfect scheduling No, you've misunderstood

fulafel 7y ago

With fine-grained parallelism, programs don't tend to start new threads per bits of work. Instead there are a bunch of worker threads that get work delegated to them in various ways. It's this way in parallelism libs for all languages. The Clojure example uses pmap, which also uses an existing pool of threads. (source to pmap shows that it's backed by futures: https://github.com/clojure/clojure/blob/clojure-1.10.0/src/clj/clojure/core.clj#L7012 https://github.com/clojure/clojure/blob/clojure-1.10.0/src/c... - futures are amply documented to be backed by thread pool)

deleted 7y ago

[deleted]