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

Show HN: uThreads – Concurrent User Threads in C and C++

samanbarghi.com

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#31

Post by comex »

krat0sprakhar wrote: post #26
zokier wrote: post #19

Earlier quoted context omitted.

Isn't raytracing almost completely CPU-bound? Seems like a odd use-case for green threads, which afaik are more commonly used for IO-bound tasks.

You're absolutely right - raytracing is CPU-bound. However, one can still parallelize per-pixel rendering computations on separate cores. Here's an example of a path-tracer written in Go, spawning a new go-routine for this very use-case https://github.com/fogleman/pt/blob/master/pt/renderer.go#L6...

If you just want to start num-CPUs threads like that code does, there is no advantage of green threads over regular ones, std::thread in C++. If you want to start a thread per pixel or something, green threads could work, but it's probably more efficient to keep track of state manually.

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#32

Post by saman_b »

michaelsbradley wrote: post #22

For what kinds of applications would one favor this over, say, the coroutines approach of libdill? http://libdill.org/tutorial.html See, in particular, Step 6 of the tutorial.

In libdill approach, you are probably limited to only multiplex connections over multiple kernel threads. And when a connection is accepted over a kernel thread it has to perform all further instructions over that kernel thread. So it gives you a bit of control over which cores to be utilized but after that you do not have control over what part of the code should be executed on each core.

Using uThreads you can decide what part of the code should be executed over each kernel thread and, if taskset is used, which core to execute your code. You can do this by creating Clusters and using migration or uThread creating in runtime. Thus you can decide which thread is used to multiplex connections and which one is used to run CPU bound code in addition to having a thread pool for example to do the disk IO asynchronously. Ultimately, one can create a SEDA[1] like architecture using uTrheads. Also you can always use uThread as a single threaded application.

------------------------------------------

[1] https://en.wikipedia.org/wiki/Staged_event-driven_architectu...

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#33

Post by CyberDildonics »

rsp1984 wrote: post #29
krat0sprakhar wrote: post #6

This looks super interesting! I've been working on a Raytracer in C++ and I was recently looking into a threading library which I can use to parallelize the rendering. Surely going to try this out in the coming weekend. Unsolicited suggestion - while benchmarks and the motivation are important for a threading library, a code snippet of a simple parallel program on the home page would be something that I'd love to see…

It sounds to me like what you'd need for ray tracing is a fork/join threading model with a master and several worker threads. OpenMP provides exactly that and is a widely supported standard. I'm curious: Why would you use anything else?

Fork and join is one type of concurrency technique, but to think you wouldn't need anything else is silly. Non shared memory concurrency and pipelined concurrency are two more techniques that can be used.

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#34

Post by CyberDildonics »

zokier wrote: post #19
krat0sprakhar wrote: post #6

This looks super interesting! I've been working on a Raytracer in C++ and I was recently looking into a threading library which I can use to parallelize the rendering. Surely going to try this out in the coming weekend. Unsolicited suggestion - while benchmarks and the motivation are important for a threading library, a code snippet of a simple parallel program on the home page would be something that I'd love to see…

Isn't raytracing almost completely CPU-bound? Seems like a odd use-case for green threads, which afaik are more commonly used for IO-bound tasks.

Yes, using green threads for ray tracing is basically nonsense, since keeping actual threads busy is no overly difficult.

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#35

Post by michaelsbradley »

saman_b wrote: post #32
michaelsbradley wrote: post #22

For what kinds of applications would one favor this over, say, the coroutines approach of libdill? http://libdill.org/tutorial.html See, in particular, Step 6 of the tutorial.

In libdill approach, you are probably limited to only multiplex connections over multiple kernel threads. And when a connection is accepted over a kernel thread it has to perform all further instructions over that kernel thread. So it gives you a bit of control over which cores to be utilized but after that you do not have control over what part of the code should be executed on each core. Using uThreads you can deci…

First time I've heard of SEDA, though I've been aware of the concerns/concepts it addresses, in various forms, for some time.

Any thoughts on Welsh's Retrospective on SEDA?

http://matt-welsh.blogspot.com/2010/07/retrospective-on-seda...

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#36

Post by saman_b »

naasking wrote: post #25

Why not just use StateThreads? A comparison against other options would be illuminating.

Good idea, I probably write a blog post on this later. If you take a look at [1], I explain the difference between N:1 and M:N mappings. StateThreads uses a N:1 mapping which means you can multiplex many fibers over a single thread and to take advantage of multi-processors you can have M processes that do N:1 mapping, which is a common practice (libmill, libdill, ...). But with uThreads you can multiplex many fibers over many kernel threads.

---------------------------------

[1]https://github.com/samanbarghi/uThreads#what-are-uthreads

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#37

Post by byuu »

aseipp wrote: post #21
jimktrains2 wrote: post #18

Earlier quoted context omitted.

Is there a reason you'd choose Apache or BSD instead of a freedom preserving license like GPL3?

They probably want to use it, make money off it, and give nothing back to anyone. The same as most people who complain about it, IMO. Or, just as likely, they'll integrate it into their own BSD software, which will then be used by someone else to make money, and give nothing back, which might as well be the same thing. (Countdown until 1 person shows up and retorts "Well, my company supports the OSS we use..." as if…

> They probably want to use it, make money off it, and give nothing back to anyone.

They do the same shit with the GPLv3 as well. Piko Interactive recently backed out of a licensing agreement with me, and just released my GPLv3 emulator in their Steam application without even telling me. When someone called them on it, they said to e-mail them for a link to the code (not enough to take my work for free, they have to play games with their obligations under the GPL.) Which by itself is useless, as it's just a UI modification. The value is the ROM image they don't include in their source, which gets you into a nasty gray area of the GPL.

It's part of the Faustian bargain all open source devs have to make: if you add a non-commercial clause, FOSS proponents will label your work "non-free" and "not open source", and you'll be banished to obscure disabled-by-default nonfree repositories on Linux distros. Which I was until I caved and moved to GPL to avoid punishing my users.

If you don't add that clause, you'll get taken advantage of. We have to rely on people being fair and sharing their profits off our work, and very often, they don't.

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#38

Post by tomjakubowski »

CyberDildonics wrote: post #34
zokier wrote: post #19

Earlier quoted context omitted.

Isn't raytracing almost completely CPU-bound? Seems like a odd use-case for green threads, which afaik are more commonly used for IO-bound tasks.

Yes, using green threads for ray tracing is basically nonsense, since keeping actual threads busy is no overly difficult.

It's not nonsense if, to render each pixel, you issue an HTTP request containing the scene/eye data and requested pixel coordinate, and wait for a response to come back from your magic render farm that lives in "the cloud". Now your "ray tracer" is totally I/O bound! :-)

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#39

Post by rsp1984 »

CyberDildonics wrote: post #33
rsp1984 wrote: post #29

Earlier quoted context omitted.

It sounds to me like what you'd need for ray tracing is a fork/join threading model with a master and several worker threads. OpenMP provides exactly that and is a widely supported standard. I'm curious: Why would you use anything else?

Fork and join is one type of concurrency technique, but to think you wouldn't need anything else is silly. Non shared memory concurrency and pipelined concurrency are two more techniques that can be used.

I was stating this in the context of ray tracing. Why not just use OpenMP and be done with it?

Re: Show HN: uThreads – Concurrent User Threads in C and C++

#40

Post by scott_s »

saman_b wrote: post #30
scott_s wrote: post #11

Earlier quoted context omitted.

I recommend trying to get access to larger machines with more hardware parallelism. I have seen techniques that scale just fine to using 16 threads, but hit serious limitations when you get to over 100 threads.

You are right, I have access to machines with higher number of cores, but they have multiple sockets and at some point I need to address the cross NUMA cost which adds a whole new level of complexity and design decisions. For sure at some point the poller thread will be saturated and the program will not scale past a certain number of threads. I used to have a poller thread per cluster for better scalability, but tha…

Sometimes, the techniques you use to scale to 100s of threads solve some NUMA issues by virtue of the fact that in order to scale that high, you need to avoid touching as much non-local data as possible. I think it's better to just deal with the pain now and start running your experiments on as large of a machine you can get access to. You can still put off explicitly designing for NUMA, but you want to avoid spending too much time and effort designing for the lower end of the scalability spectrum.
Post reply on HN