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

21–30 of 64 posts

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

#21

Post by aseipp »

jimktrains2 wrote: post #18
jtsylve wrote: post #13

Is there any reason you chose GPL3 or would you consider a less restrictive license like Apache or BSD?

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 it's meaningful at all, vs the massive trend of corporations ripping off FOSS and returning nothing)

I don't GPL license a lot of my software (I used BSD/MIT/Apache most of the time, and my company revolves around and writes BSD-licensed code), but IMO, having seen this tired argument over and over again, I'm pretty sure 90% of all GPL complaints come down to this, even if the people don't come out and say it: "I can't make money off of your free work as easily, and that isn't fair to me. Please reconsider." Given this is Hacker News where half of everyone is in a rat-race to make money, I speculate this is a strong part of it.

People just like to wrap it in words like "restrictive" and "viral" to make themselves sound more palatable and reasonable.

And of course, there are also many reasonable alternatives to this library, many which are BSD or permissively licensed, which these people could also use instead -- but that won't stop them from complaining that GPL is unfair or "bad", of course, even though they could pick from a dozen alternatives...

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

#23

Post by jtsylve »

protomikron wrote: post #15
jtsylve wrote: post #13

Is there any reason you chose GPL3 or would you consider a less restrictive license like Apache or BSD?

Can we please stop calling out nearly every project that uses GPL (3) and call it restrictive? I know there are different opinions and arguing which is "better" nearly always leads to a philosophical debate on principles that gets us nowhere. Sorry if this sounds snarky, and I do not blame you in particular, but it is just a theme I have encountered here the last years that I find toxic as it portrays the GPL (and FS…

I don't think that the GPL or the FSF is bad or evil. I've released and maintain several projects that are GPL licensed.

GPL is by definition more restrictive than Apache and BSD, since there are more requirements to use the code, so asking if the developer is willing to consider a less restrictive (not "better") license shouldn't be met with hostility.

My motivation for asking is simply because the project looks interesting and potentially useful; however, the proprietary nature of my current work means that GPL licensed code isn't really an option for me. I absolutely wouldn't hold it against the author if they chose GPL for this or any other reason.

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

#24

Post by protomikron »

module0000 wrote: post #16
protomikron wrote: post #15

Earlier quoted context omitted.

Can we please stop calling out nearly every project that uses GPL (3) and call it restrictive? I know there are different opinions and arguing which is "better" nearly always leads to a philosophical debate on principles that gets us nowhere. Sorry if this sounds snarky, and I do not blame you in particular, but it is just a theme I have encountered here the last years that I find toxic as it portrays the GPL (and FS…

Not sure what the OP's motivation are for asking "why GPL?", but my motivation when I ask that can translate to something like this: "Hi, I'd like to use your library, but your license is incompatible with the other licenses in my codebase. Consider BSD please?"

"Don't ask the author of a library why it is incompatible with proprietary licenses. Ask why your codebase is incompatible with open licenses."

JFK

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

#26

Post by krat0sprakhar »

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.

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...

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

#27

Post by jtsylve »

saman_b wrote: post #17
jtsylve wrote: post #13

Is there any reason you chose GPL3 or would you consider a less restrictive license like Apache or BSD?

Yes, there is a specific reason behind it, but in the future I might consider a less restrictive license.

Thanks for the reply and your future consideration. I'm glad you seem to have taken the question as it was intended. I certainly didn't mean to imply that one license is superior to another.

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

#28

Post by protomikron »

jtsylve wrote: post #23
protomikron wrote: post #15

Earlier quoted context omitted.

Can we please stop calling out nearly every project that uses GPL (3) and call it restrictive? I know there are different opinions and arguing which is "better" nearly always leads to a philosophical debate on principles that gets us nowhere. Sorry if this sounds snarky, and I do not blame you in particular, but it is just a theme I have encountered here the last years that I find toxic as it portrays the GPL (and FS…

I don't think that the GPL or the FSF is bad or evil. I've released and maintain several projects that are GPL licensed. GPL is by definition more restrictive than Apache and BSD, since there are more requirements to use the code, so asking if the developer is willing to consider a less restrictive (not "better") license shouldn't be met with hostility. My motivation for asking is simply because the project looks int…

Fair enough, I know the situation well, it just came up a lot in recent times.

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

#29

Post by rsp1984 »

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?

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

#30

Post by saman_b »

scott_s wrote: post #11
saman_b wrote: post #4

Earlier quoted context omitted.

Hi, I developed uThreads. I looked at lthreads quickly, and it seems lthreads only maps multiple coroutines onto a single pthread (N:1). Although, it adds the possibility of running multiple pthreads, but each pthread can only run their local lthreads (using M threads that do N:1 mapping). However, in uThreads, uThreads can be multiplexed over multiple pthreads (thus M:N mapping). Also lthreads scheduler is based on…

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 that would add overhead for migrations between clusters, thus I had to remove it for now until I can somehow find a low overhead solution. uThreads is a work in progress and all these need to be carefully considered in the future :) Thanks for your feedback

Post reply on HN