171–180 of 301 posts
Earlier quoted context omitted.
How did the BeOS designers make the BeOS so good at multiprocessing? I remember how well the operating system scaled with more than one CPU.
Probably because it ran on PowerPC. If I remember my systems design class from 20 years ago, RISC makes implementing or scaling multiprocessing easier.
Earlier quoted context omitted.
How is that an example an improvement over c++? C++ has had pragmatic omp parallel for for two decades
I'm not familiar with OMP, so please forgive me if I'm incorrect - but OMP from my quick search appears to be thread based, while go routines are much lighter weight than threads. They have their own scheduler - which like most things is both good and bad depending on what you want them for. If you use them as intended, the internal scheduler is a great design decision. This means I can happily spawn 10,000 without c…
This is probably exactly the same behavior as goroutines.
Earlier quoted context omitted.
Wrong. Goroutines are not simply coroutines. GOMAXPROCS defaults to number of cores.
Prove it. Prove it by replacing Sleep in your example with some number crunching, and show how it scales with the number of cores in your CPU.
Earlier quoted context omitted.
As someone who frequently posts about my personally-excellent experiences with Rust, what makes you suspect it's astroturf rather than just turf? You think Mozilla is paying people to post about Rust using puppet accounts? C'mon.
It does seem a little odd that every comment about Rust gushes about its progress and stability without discussing any downsides. One would be similarly suspicious if, e.g., Perl6 were discussed this way.
You see the same with Rust, Elixir, VSCode, Elm, Purescript, ReasonML, etc.
It's not astroturfing, it's just a lot of beginners that are overly excited to proselytize their new discovery.
Earlier quoted context omitted.
As someone who frequently posts about my personally-excellent experiences with Rust, what makes you suspect it's astroturf rather than just turf? You think Mozilla is paying people to post about Rust using puppet accounts? C'mon.
It does seem a little odd that every comment about Rust gushes about its progress and stability without discussing any downsides. One would be similarly suspicious if, e.g., Perl6 were discussed this way.
I've experienced plenty of frustration, albeit outweighed by the massive benefits for my use case. And there are whole problem domains to which it's just not suited. I see these mentioned pretty frequently.
I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…
There has. It's called a GPU. Things like OpenCL and CUDA are the new languages.
https://www.karlrupp.net/2018/02/42-years-of-microprocessor-...
Earlier quoted context omitted.
A really powerful outworking of it is seen in the Rayon crate, where you can change a sequential iterator into a parallel iterator just by adding the crate, importing the trait and changing `iter` to `par_iter`. If it’s not thread-safe to do, then it won’t compile. (That’s the big difference from C++.) If it is, it will, and it’ll be smart about how it runs, spreading the load across all available cores pretty much o…
FWIW, you can also achieve similar behavior in Clojure via pmap, Reducers, etc.
And in .NET https://docs.microsoft.com/en-us/dotnet/api/system.threading...
And in Java https://blog.oio.de/2016/01/22/parallel-stream-processing-in...
Rayon is notable because Rust is a native-compiled, no-GC language.
I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…
> I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardware system There has. It's called a GPU. Things like OpenCL and CUDA are the new languages.
It's partly what made the PS3 so hard to write for, the SPUs only have 256kb of directly addressable memory, everything else is DMA'd. That said when you had your code+data fitting in 256kb it screamed everywhere else as well since you fit in L1+L2 cache neatly.
I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…
> I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardware system There has. It's called a GPU. Things like OpenCL and CUDA are the new languages.
With the current fragmented and sometimes proprietary forest of programming platforms, an application needs to be quite specialized to warrant investment in GPU compute outside the original niche of graphics acceleration. There are other giant problems too, after you get over rewriting your application for numerous different platforms - atrocious quality of GPU drivers causing OS crashes for users, lack of any common way to debug GPU code, the colourful quality of compilers, the wildly different performance characteristics of different platforms necessitating per-platform algorithm changes, etc...
Consider what a minority of applications bother to even put in the work to exploit large amounts of CPU parallelism, which is vastly easier. There is after all >10x parallelism available on a typical PC CPU, after you count cores, threads and SIMD lanes.