Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rationale: Or why am I bothering to rewrite nanomsg?

nanomsg.github.io

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Rationale: Or why am I bothering to rewrite nanomsg?

#51

Post by ezdiy »

viraptor wrote: post #46
otabdeveloper1 wrote: post #42

Earlier quoted context omitted.

There's no such thing as a "context switching overhead". You don't understand how operating systems work. The OS context switches to the next available thread at fixed time intervals. It doesn't matter if you have 5 threads or 5000, the number of context switches is the same. The only difficulty is deciding which thread is the "next available" one. This is the job of the process scheduler. Normally, the process sched…

> There's no such thing as a "context switching overhead". So what do you call the time spent changing the system internal information about the currently executing thread, switching page tables via cr3 and the invalidation it causes, and the time wasted because of cache misses (although a lot of it can be reclaimed with CPU pinning). Because that's what people normally call "context/thread switching overhead" > The…

TLB is only an indirect cause. This is because kernel scheduler preempts processes fairly infrequently (100 or 1000hz, or dynamic, but still capped to a small number).

Scheduling quantums are so large precisely to keep TLB flush overhead of a context switch low. If a network mandates more interaction (say, 100k req/s across all workers), each quantum tick must process a queued bundle of 1000 requests which piled up while asleep. This works as designed - you're supposed to use up all of your quantum, and not terminate it early by issuing blocking IO per request. One prerequisite for this is that your network/disk protocol must be pipelineable (most are because thats how we deal with network/seek latencies).

But at certain point the overhead of this pipelining itself becomes so great (message queues too deep) you have to switch to threading.

Hardcore threading advocates on the other hand, need to account for overhead of atomics (for locking, or for "lockless" algorithms). An atomic must wait for all pending writeback flush. Threading gets a lot of bad rep not because "kernels suck at it", but because person making such a statement wrote their program as an exercise in lock contention and/or too much write cache pollution per single atomic.

Threading vs process tradeoff = deep pipeline overhead vs frequent queue flush+locking overhead tradeoff.

Typically, you need to meet somewhere in the middle for best performance, which is when you end up with threads with job queues - those basically emulate process-induced queues within thread model.

Re: Rationale: Or why am I bothering to rewrite nanomsg?

#52

Post by steveklabnik »

lmm wrote: post #50
bpicolo wrote: post #47

Earlier quoted context omitted.

They intentionally removed green threading from Rust long ago, so I would guess they intend to leave it outside core? https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b...

I think the intention is that userspace schedulers (event loops) will remain outside of core, but core will potentially contain a task interface and know how to form tasks (but not necessarily offer any way to execute them asynchronously) so that there can be better integration of ownership/borrow checking with async tasks? But I haven't been following that closely.

Yes, this is basically correct. There's an open RFC to add futures to libcore; https://github.com/rust-lang/rfcs/pull/2395

But we have no plans on pulling anything more than that in.

> so that there can be better integration of ownership/borrow checking with async tasks?

It's more about conventions and stability; traits are a great thing to put in the stdlib so the entire ecosystem can use them as an interface.

Re: Rationale: Or why am I bothering to rewrite nanomsg?

#53

Post by theincredulousk »

adrianratnapala wrote: post #25
theincredulousk wrote: post #21

This is at least partially ill-advised. Comes off as an expertly done, but same old refactoring project that could be titled "I didn't understand this and would understand it better if I were designed based on my personal preferences". This is reinforced by the probably approaching 1 that nobody needs another "six of one half dozen of the other" message queue framework, and alluding to an belief that the C++ library…

> There is some stigma that visualization is for fakers - "real programmers only use a bare text editor" That stigma would have gone away long ago if the actually existing visual languages were less wretched. (I'm looking at you LabView!). No doubt there are better languages than LabView, but while I think a visual language can be good, creating one will involve many as-yet-unknown unknowns. So even good attempts wil…

Once someone makes this that works properly with arbitrary C/C++ and threads/interrupts, I honestly believe it will be a revolution in productivity.

As mentioned below, others (esp. IDA) make it so glaringly obvious that how you were working before was way harder than it had to be.

Re: Rationale: Or why am I bothering to rewrite nanomsg?

#54

Post by theincredulousk »

tuukkah wrote: post #34
theincredulousk wrote: post #21

This is at least partially ill-advised. Comes off as an expertly done, but same old refactoring project that could be titled "I didn't understand this and would understand it better if I were designed based on my personal preferences". This is reinforced by the probably approaching 1 that nobody needs another "six of one half dozen of the other" message queue framework, and alluding to an belief that the C++ library…

> All that said, State Machines are (currently) the one true abstraction for a given program because that is what a computer is, and every program is, to begin with. I don't understand these claims. To me, a computer "is" processors that step through memory locations interpreting them as operations and operands - not a state machine. Equally, hardly any program is a state machine. Is a Haskell program a state machine…

The immediate side-effects of any program and the processor are only to read, manipulate, and write data. Data is stored in a finite memory that all have states 0 and 1.

Every single thing that can be represented or manipulated by a program is just an array of 0s and 1s that are read, manipulated, and written. The values in the array are the state, and everything a program is capable of doing only moves it to a different state of memory.

Every single program ever written is a state machine, so is every microchip for that matter.

https://en.wikipedia.org/wiki/Turing_machine

Re: Rationale: Or why am I bothering to rewrite nanomsg?

#55

Post by theincredulousk »

jclulow wrote: post #30
theincredulousk wrote: post #22

Earlier quoted context omitted.

Of course no offense, but the author does seem to be somewhere shortly after the first peak on the Dunning-Kruger curve. Even truly embedded systems with an OS like QNX don't "melt" with 100 threads. Obviously he "doesn't know what he doesn't know" in expertise terms, and blamed a mistake on the operating systems. That combined with the other extremely dubious reasoning - e.g. (see my other very long comment) how rep…

I think Garrett has been doing all of the things you're talking about for quite a long time. I'm not saying this experience makes him correct per se, but come on -- this is just poorly constructed character assassination on your part.

In retrospect this is probably true. Should have left it at the comment about QNX - the rest is honestly irrelevant.

Apologies to Garret for assassinating his character based on a single blog post.

Re: Rationale: Or why am I bothering to rewrite nanomsg?

#56

Post by dmitrygr »

ezdiy wrote: post #51
viraptor wrote: post #46

Earlier quoted context omitted.

> There's no such thing as a "context switching overhead". So what do you call the time spent changing the system internal information about the currently executing thread, switching page tables via cr3 and the invalidation it causes, and the time wasted because of cache misses (although a lot of it can be reclaimed with CPU pinning). Because that's what people normally call "context/thread switching overhead" > The…

TLB is only an indirect cause. This is because kernel scheduler preempts processes fairly infrequently (100 or 1000hz, or dynamic, but still capped to a small number). Scheduling quantums are so large precisely to keep TLB flush overhead of a context switch low. If a network mandates more interaction (say, 100k req/s across all workers), each quantum tick must process a queued bundle of 1000 requests which piled up w…

   > Threading gets a lot of bad rep
   > not because "kernels suck at it",
   > but because person making such a
   > statement wrote their program as
   > an exercise in lock contention
Well put. I'm going to have this printed on a plaque and hung above my desk.

Re: Rationale: Or why am I bothering to rewrite nanomsg?

#57

Post by dmitrygr »

AstralStorm wrote: post #39
jesseb wrote: post #16

Earlier quoted context omitted.

I raised an eyebrow at that as well. My workstation running Windows 10 is currently chugging along with 236 Processes, 3564 Threads and 154915 Handles, which is pretty typical of this system.

Of those, how many are actually active? (equivalent to R state in procps)

if num_active_processes is much larger than number of cores, then your software architecture is wrong and you're just stress testing your OS's lock primitives and CPU's TLB logic.

Lots of threads/processed blocked on stuff is ok. Lots of them all wanting to run and be CPU bound is bad design

Re: Rationale: Or why am I bothering to rewrite nanomsg?

#58

Post by tuukkah »

theincredulousk wrote: post #54
tuukkah wrote: post #34

Earlier quoted context omitted.

> All that said, State Machines are (currently) the one true abstraction for a given program because that is what a computer is, and every program is, to begin with. I don't understand these claims. To me, a computer "is" processors that step through memory locations interpreting them as operations and operands - not a state machine. Equally, hardly any program is a state machine. Is a Haskell program a state machine…

The immediate side-effects of any program and the processor are only to read, manipulate, and write data. Data is stored in a finite memory that all have states 0 and 1. Every single thing that can be represented or manipulated by a program is just an array of 0s and 1s that are read, manipulated, and written. The values in the array are the state, and everything a program is capable of doing only moves it to a diffe…

I see. I think your argument falls apart when you wave away the differences (e.g. memory) between a finite state machine, a Turing machine and an actual computer.

Theoretically, the Turing machine and lambda calculus are equivalent: https://en.m.wikipedia.org/wiki/Church–Turing_thesis

However, in practise, the specifics of programming languages are essential: https://en.m.wikipedia.org/wiki/Turing_tarpit

When you include the state of the memory in the state of the state machine, the state space explodes, which is more than inconvenient.

On the other hand, in lambda calculus and Haskell, you don't have to even think about state.

Re: Rationale: Or why am I bothering to rewrite nanomsg?

#59

Post by daurnimator »

spacenick88 wrote: post #36
rumcajz wrote: post #27

Original author of zmq/nanomsg here. After all those years dealing with the problem of implementing network protocols I believe that this entire tangle of problems exists because we are dealing with something like 35 years of legacy in two different but subtly interconnected areas: concurrency/parallelism and network programming APIs. The area of concurrency/parallelism started quite reasonably with the idea of proce…

So for me the really big question in all of this is "Are threads really too heavyweight?". This obviously needs the constraint "on a sane, modern OS". For me the most sane C (non-datagram) networking model at least on Linux is threads, each calling accept concurrently (afaik few people know this is supported) and then handling the accepted connection until that is closed. For systems where you only want to handle a f…

> "Blabla uses async epoll so handles 10k connections" but a) what serious work can you do with 10k connections i.e. 125 kB/s per connection @ 10 Gbit/s.

One example where I've done+needed this is an XMPP server.

A much more common example is a HTTP server with lots of idle keepalive connections.

Re: Rationale: Or why am I bothering to rewrite nanomsg?

#60

Post by rumcajz »

rumcajz wrote: post #35
twic wrote: post #33

Earlier quoted context omitted.

1985 called, they want their composable networking abstraction back: https://en.wikipedia.org/wiki/STREAMS

Yes, exactly. After all, as Jack Weinberg said, never trust anyone below 30.

For reference here's the original Streams design paper by Dennis Ritchie. Worth reading. https://cseweb.ucsd.edu/classes/fa01/cse221/papers/ritchie-s...
Post reply on HN