No mature, sensible code allows for 10x performance improvement (let alone...).
Every time I see a statement like this I take it as a confession.
178 karma · joined August 11, 2017
[0] https://en.wikipedia.org/wiki/The_Steamroller_and_the_Violin
> demo1: ... JFR will not report anything useful at all, since it cannot traverse stack traces when JVM is running System.arraycopy()
I'd rather run jstack in a loop than lose System.arraycopy() (or, in fact, any native code be it JVM's or JNI).
They are not. There are orders of magnitude more rocket scientists than good profiler writers. And no, bottle rockets with flight recorders do not count.
... or sideways!
If you want a visual model that may help to build some intuition about that, I have one at [1]. Retrocausality is not explicitly spelled out in that model but "it's uh... uh... it's down there somewhere".
> Multi-dimensional RS codes are an easy way to get to an absurdly huge size for real.
"Multi-dimensional" may mean 3,4,..,10 dimensions. "Absurdly huge" means a petabyte and beyond. "For real" means practical recovery of swaths of lost or damaged data. "Fountain LDPC codes" are essentially one-dimensional. Extending them to the ability of recovering an annihilated data center would make them impractical. Making them multi-dimensional would make them inferior to RS (which is still MDS in every single dimension).
Multi-dimensional RS codes are an easy way to get to an absurdly huge size for real (granted they stop being MDS). Long term archiving is an obvious application. One-way communication, like in deep space, is another. Though, speed requirements are less demanding there. That one tried to push the envelope for a one-dimensional RS code to those limits is a curiosity. Some techniques may be useful in other practical approaches. It's a pity the code representation had to depart from GF(2^n).
Yeah, this is how recursion works. "If it ain't broke, don't fix it" maybe?
> The italian renaissance started in the 14th century for sure and maybe even in 13th century depending on who you ask. Though the exact date can be disputed, nobody disputes the fact that it started long before the fall of the byzantine empire in the mid 15th century.
The early "Renaissance" was Latin, the Renaissance proper was Greek. That's all you need to know to figure out when (1397+), where (Florence+), and how it started. The seed is more important than the soil.
That line of argument makes no difference between the free will of humans and that of animals, insects, bacteria or rocks. But that can't possibly be true: we humans invented free will after all. That's the mental gymnastics that keeps me mentally strong. No beast, nor angel. "Freedom evolves" (DD).
One point is actually that the parallel quick sort algorithm is a bad benchmark for task schedulers (it doesn't scale well for one thing). Another point is, well, that one can spend two years of deep technical work and then be easily beaten by some "legacy" tech in the course of a morning exercise. Maybe those bearded guys were good for something after all :)
Go (go1.17.1 darwin/amd64)
took 5.591593544s
took 5.285948722s
took 5.218750076s
took 5.239224787s
took 5.131232207s
took 3.48s
took 3.37s
took 3.44s
took 3.43s
took 3.49s
Time: 2684 ms
Time: 2654 ms
Time: 2840 ms
Time: 2676 ms
Time: 2649 ms
Actually, 26% (55/210). You say 25% and nobody notices. You say 26% and you convey a message you understand things on a deeper level (still shallow but much, much better than no level at all). I'd pick 27%, though.
Imagine a DAG with million nodes. Each node takes data from all its input edges, processes it and sends to all its output edges. Now that I have light threads I want to use them to implement all nodes. Edges are naturally implemented as blocking queues. If I feed enough data into this structure I get a CPU-bound workload with a lot of concurrency (and scalability). Yet the nodes will have to block on their input queues because data will not be ready in most cases.
Now, to complicate the design, I want to have I/O tasks that read data from a file/network and feed it into the DAG and send its resulting output to the UI thread. Should I use different "threads" for different parts of the design? I'd hate to, especially given the fact that all those parts are dynamic in nature.
So, of course, I'm not currently spawning a million threads to execute all those tasks but Loom says I could do that for all my tasks and my concern is that to get decent performance I'd have to explicitly separate my "CPU-bound" tasks from my "I/O-bound" tasks and use different kinds of threads for each (which I'm kind of doing right now but again the promise was...).
I expect internal implementation of continuations in Loom to have non-negligible overhead which may be justified for heavy blocking I/O operations but not for CPU-bound workloads. One benchmark I'd like to see (I may want to create it myself at some point) would run a large number of light threads (fibers) which would exchange data via blocking queues (to mimic goroutines with channels). No I/O, a totally CPU-bound workload with a lot of concurrency and a good potential for scalability. Somehow, I'm not very optimistic about Loom's performance in that context (please tell me if and where I'm wrong).
[-1] Not the right time to smile https://www.svoboda.org/a/28088763.html
Another possibility is that the thread dies while holding a mutex (or exclusively possessing a resource). It may seem like a stretch for shared memory systems, but not so much for distributed systems. Recovering the resource is not an easy task, especially considering the fact that recovering threads may also die or that the thread assumed dead all of a sudden returns to life. In my opinion, making a parallel system robust to that kind of malfunction goes far beyond what the industry considers acceptable as lock-free algorithms. I gave some thought to that scenario in my project Robusta [1]. I doubt it could be useful for any practical purpose but at least it works for a universal computational model.
Now if you realize that that $100 is a mere IOU from the U.S. of A. you may get a feeling you are onto something...
[0] "Кто за стеной?" (1977) https://www.youtube.com/watch?v=ECvsD4b0JlU
One such reference might be "Strong and Weak Emergence" by David Chalmers [0], given the fact that "weak" emergence was introduced but "strong" emergence was not even mentioned (though indirectly implied).
German researchers want to send out hundreds of thousands of coronavirus-antibody tests over the coming weeks, Der Spiegel reported.
People who test positive for the antibodies could be given an "immunity certificate" that would allow them to leave their coronavirus lockdown early.
Other countries, including the United Kingdom, are planning mass testing to ease lockdowns.
https://www.businessinsider.com/coronavirus-germany-covid-19...