etep

The edit distance form work to zork is 1.

For this, and because of tab completions (perhaps tab completions post-date zork, but nonetheless) I find the work:zork story compelling. I have used the first letter is replaced by "z" trick many times (z-tab, done!), and that pre-dated any contemplation of the zork mystery.

Surfer deserves to hit the front page also. Much better than gtk wave. Nice work Spade & Surfer!

I'm curious about the results under the section titled "Demonstration."

The author claims that ground truth is that each goroutine utilizes 10% of the CPU time (so stipulated that this should be the case). But, what if the results shown are accurate, i.e. that the results are the actual CPU time (because of idiosyncrasies of scheduling between the OS, the go runtime, and anything else happening on that system).

Does running the new profiler show less variance in the results from that initial experiment? Showing this result would strengthen the claim that the "out of the box" solution is inaccurate.

Wasn't aware of it, will try it - thank you!

I have a theory that news occurs with a far lower frequency than people think, far lower than even when people try to account for their knowledge of the 24 hr. news cycle. In my theory, most of what counts for news, is either a story update (737 Max stories), or not news (say Trump "news").

My hypothetical news organization would strive to identify the unifying element of a given news item, and then keep one article about them. The article would include the following elements: a summary, a timeline, a fact set, and a commentary or critique. All subsections would be allowed to evolve, but the "story" would be one thing.

I've considered trying to self fund this somehow, but I've never convinced myself that it would really get traction.

Thank you for the insight! Just for clarity, I'm using "autopilot" as a catch-all term that refers the automated systems that plausibly seem to have caused these crashes.

It's not nice that so many writers parrot that the solution is "more pilot training." Under the hypothesis that there needs to be a solution (one that I think is correct), then the answer of more training amounts to mere hope. One hopes that the pilot a) knows and b) remembers to turn off the autopilot when the emergency starts.

For chips, power scales with voltage squared. Is also true that P=IV (since both are true, these observations cannot be in contradiction). Apparently, for chips, the current must be proportional to voltage also. Glossing over some details, turning on (off) a transistor is the same as charging (discharging) a capacitor. The energy stored on a capacitor is 1/2 C V^2. If you turn on and off the transistor periodically (say with frequency f) you use 1/2 C V^2 energy f times per second (energy per unit time is power). Normally the capacitance is ignored when discussing how power changes because for a given design the capacitance is a fixed quantity.

I think it is linear for frequency and non-linear for voltage, i.e. P~fCV^2. But in many current CPUS, the feature that adjusts frequency also adjusts voltage. That's why I stipulated that, for my comments to be true, such shenanigans as dynamic frequency (and voltage) scaling must be "turned off." I think the OP was asking, what happens to CPU energy if you load the web page with and without the optimized compilation. The OP was interested in core sleep states, but I think that dynamic frequency scaling is a confounding factor. It would be interesting to see the measurements w/ and w/out that feature perhaps.

It should be the case that if the same amount of work is done, then the energy used will be the same. If it takes less work to compile the web assembly, then less energy (holding all other parameters the same). If you have to idle a CPU, then you probably use more energy (holding all other parameters the same) i.e. because you will spend more time and accomplish the same amount of real work (but waste energy on the idled core, albeit waste very little, accomplishing extra, but non-productive, work). Cannot let some other CPU parameter changes as a result of cores being idled (e.g. frequency gets boosted on non-idle cores as a result of dynamic frequency scaling with idle cores) to run this experiment. Thinking about CPU energy use is interesting :)

If Bezos gave all his money to everyone in the world we would all get maybe $13 or so. If all the billionaires did the same we would all get $1000 or so.

Hi stjepang,

If the following criteria is met, then perhaps the branch mis-predict penalty is less of a problem: 1. you are sorting a large amount of data, much bigger than the CPU LLC 2. you can effectively utilize all cores, i.e. your sort algorithm can parallelize Perhaps in this case you are memory bandwidth limited. If so, you are probably spending more time waiting on data than waiting on pipe flushes (i.e. consequence of mis-predicts).