omazurov

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.

omazurov

3년 전discuss

My personal recommendation for a Tarkovsky's first is his diploma film The Steamroller and the Violin (1960, 46 min, co-written with Andrei Konchalovsky). It was surprisingly watchable [for me] and I wish I had watched it first myself before I was exposed to the Mirror when I was 16.

[0] https://en.wikipedia.org/wiki/The_Steamroller_and_the_Violin

omazurov

3년 전discuss

You get JFR's precision but inherit its blind spots as described in [1]:

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

[1] https://github.com/apangin/java-profiling-presentation

omazurov

3년 전discuss

>Profilers are not rocket science...

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.

omazurov

3년 전discuss

>...retrocausal models also open avenues of exploring a “time-symmetric” view of our universe, in which the laws of physics are the same regardless of whether time runs forward or backward.

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

[1] https://github.com/OlegMazurov/Janus

omazurov

4년 전discuss

Necessity is the mother of invention? (Голь на выдумки хитра? :( )

omazurov

4년 전discuss

I can only repeat my initial statement:

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

omazurov

4년 전discuss

I'm not talking about CD-ROMs or immediate availability in any form. How would you encode a petabyte (for a starter) with LDPC/Turbo? Not available right away but accumulated over months with no predefined upper limit? Computational cost remains an important factor but other requirements take over.

omazurov

4년 전discuss

> Larger and larger block sizes are important. LDPC probably is the more practical methodology today, though I admit that I'm ignorant about them. Still cool to see someone try to push Reed Solomon to such an absurdly huge size though.

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

omazurov

4년 전discuss

> But I’m here to tell you they got it wrong, and everyone’s been getting it wrong ever since. Students come away underwhelmed and baffled, and go on to become the next generation of teachers who repeat this process.

Yeah, this is how recursion works. "If it ain't broke, don't fix it" maybe?

omazurov

4년 전discuss

That's why there should be another parameter: you should split the key into N parts so that any M <= N can open the lock. You can increase M adding people you don't trust 100%, say to 8, but leave N at your comfortable level, 5. Even if those 3 conspire, they would still be 2 people short of being able to break the lock. You can do 12:5, give 5 parts to your spouse and spread the remaining 7 among your relatives and friends. There will still be a single point of failure, though, if somebody steals all 5 parts from him/her. You can decide to decrease allocation to only 4 parts so that your spouse would need to cooperate with any of the other trusted parties. The point is there is enough room for designing a scheme that is both secure and reliable.

omazurov

4년 전discuss

>> helped kindle the European Renaissance as we know it.

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

omazurov

5년 전discuss

> Free will does not exist. It is logically inconsistent...

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

omazurov

5년 전discuss

It's plain Java (i.e. JVM/JIT), ForkJoinTask based implementation. As in the original implementation, measurement is done around the quickSort() call.

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 :)

omazurov

5년 전discuss

Increasing the size of the array 10x (100_000_000) and filling a glaring omission:

Go (go1.17.1 darwin/amd64)

    took 5.591593544s
    took 5.285948722s
    took 5.218750076s
    took 5.239224787s
    took 5.131232207s

Zig (0.9.0-dev.959+f011f1393)

    took 3.48s
    took 3.37s
    took 3.44s
    took 3.43s
    took 3.49s

Java (openjdk version "17-ea")

    Time: 2684 ms
    Time: 2654 ms
    Time: 2840 ms
    Time: 2676 ms
    Time: 2649 ms

MacBook Pro Early 2013, 2.7 GHz Quad-Core Intel Core i7, 16 GB 1600 MHz DDR3

omazurov

5년 전discuss

> Instead of memorizing 20x20 combinations, you limit yourself to a standard 10x10 table (just 25% of all combinations)

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.

omazurov

5년 전discuss

Please see my example below.

omazurov

5년 전discuss

> If you're spawning one million threads, each of which will perform a blocking operation, then you're likely not CPU bound

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

omazurov

5년 전discuss

I thought the promise was we'd use Threads for everything and forget to worry about blocking calls. I can't run one OS thread per CPU in my proposed benchmark: I want to run millions of threads. Reimplementing it in a different concurrency model would mean Loom is hopeless for such workloads. Go may perform better but I don't think it would perform well (I see, I now have to implement my benchmark in go as well). I just don't believe their scheduler is so good.

omazurov

5년 전discuss

>... delimited continuations (of some form)

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

Submissions

Rockwell Automation Retro Encabulator PR

Show HN: Chaotic Life – deterministic behavior from unsynchronized threads

comments