cospaia

Awesome. Would you consider adding this experiment to the repo? https://github.com/PEZ/ghost-chase-condition/tree/master/tes...

Or, if that's a too big ask, just give me some hints how to do it, and i'll update the repo.

Haha, yes, you are reading correctly. To clarify: my employer bought the machine for me to have for this purpose. They know how grumpy I get with unsolved mysteries.

I've now made an experiment that removes System.currentTimeMillis() as a suspect: https://github.com/PEZ/ghost-chase-condition/tree/master/tes...

Thanks! I’ll try this when I’m at the computer.

This machine https://www.dustin.se/product/5011255694/mini-pc-pn51

Ubuntu, latest LTS.

I bought the machine for this purpose. Guessing it was sufficiently similar to the machines running the benchmarks where I stumbled across the issue: https://plummerssoftwarellc.github.io/PrimeView/?rc=30&sc=dt...

Not certain. But there are a lot of implementations very similar to mine in tons of other languages and vms. None display this afaik. Also I get different behavior with JVM/JDK 7.

Yes, I should try to profile each run and compare the profiles of the bad and good ones.

Would be quite funny if it's in the System.currentTimeMillis() call this happens. I'd try to figure out a way to remove that from the picture...

It's a mini-pc. Could be throttling. There are benchmarks written in tons of languages here: https://github.com/PlummersSoftwareLLC/Primes I've so far only seen this behaviour with the JVM involved.

Yes, 1X, 0.5X are a bit arbitrary. I mean 1X as the speed I know it can run at. So it could well be that with JDK7 the optimizations could not happen and that the question then is why the optimizations do not always happen.

Making each run longer, 1 minute instead of 5 seconds displays the same performance toggling:

0 - Passes: 72705, count: 78498, Valid: true 1 - Passes: 33140, count: 78498, Valid: true 2 - Passes: 71867, count: 78498, Valid: true 3 - Passes: 33137, count: 78498, Valid: true 4 - Passes: 72264, count: 78498, Valid: true 5 - Passes: 72062, count: 78498, Valid: true 6 - Passes: 33021, count: 78498, Valid: true 7 - Passes: 33053, count: 78498, Valid: true 8 - Passes: 71902, count: 78498, Valid: true 9 - Passes: 33024, count: 78498, Valid: true

(JDK17 in this case)

A datapoint I just discovered. On JDK7 the performance is stable at the 0.5X level. It starts to toggle between 0.5X and 1X on JDK8.

I'm stumbling onto a strange Java performance irregularity, especially easy to hit with Docker on Linux. A super straightforward implementation of Eratosthenes sieve using a Java BitSet for storage, sometimes drops in performance by 50%. Even more with JDK8. Any JAVA/JDK/JVM experts here that can shed some light on the mystery for me? I've been at it a while, but it is quite a bit outside my field of knowledge, and I am out of ideas for how to proceed. The blog article linked + the Git repository is an attempt to summarize/minimize things.

You are on to something with ”behaviour”, ”actors”, and ”rational” . Ludwig von Mises defined ”rational” as ”aiming to an end, using means”. That means that even someone performing a dance to produce rain is a rational actor. He formulated the axiom that ”humans act”. And then derived his theory from that. The science is named Praxeology. A big difference from the natural sciences is that you really can't falsify a theory using empirics. There is no way to repeat an experiment, because reality has been reconfigured. Therefore axiomatic theory is what you have to rely on. Which is not too bad. After all sciences like geometry also make do without empiricism. (There is no way to empirically disprove that a triangle has an angle sum of 180 degrees.)

No, it can't be a science like physics. It is a science anyway. Just not like physics.

A long Twitter thread about a non-lack of big problems, about parentheses, and about using git bisect to solve hard programming issues.

Thank you!

TL;DR: Two (OK, maybe three) clicks and you are evaluating Clojure code in a full blown editor environment running in your browser. And that's where you will start learning Clojure.

Guides for beginners picking up Clojure often start with you installing stuff which also brings on choosing the tooling to use and what editor, and what plugins, and so on. This can throw you off track, and reportedly feels a bit overwhelming for many people. It also often takes you via a REPL prompt that you later are not supposed to use very much. (You are supposed to use the REPL as it lives in the Clojure files building up your application.)

Leveraging Gitpod, VS Code, the Clojure extension Calva (which I created), and Clojure itself, I here take the approach of guiding you directly to the mode of Interactive Programming that we Clojurians never stop talking about. It is in this mode you then learn the basics of the Clojure language. The bet is that you will like it so much that you are eager to spend the energy needed to figure out what to install to create yourself a productive and ergonomic Clojure development environment.

This is the first version, and just released. There'll be dragons. Knowing this, anyone here curious enough about Clojure to help me test how this works for you as a guide to start with the language?

It would be lovely with a video demo of this!

It will depend on what features your workflow appreciates. Being the creator of Calva I am biased, of course, but it certainly supports my workflow.

The big culprit right now is that Calva doesn't handle large results well at all. I find strategies around it, but it is a thing that really needs to be fixed and it will be in focus during the Clojurists Together funding.

Another feature lacking, that CIDER has, is a step debugger. Something that doesn't affect my workflow very much, but I know some people will lack it. It is also part of what we will try to fix during the CT funding period.