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.
We're building a crypto exchange, on a chip. We sell ultra-low latency market access to HFT participants through our on-chip λ API. For all other participants, we offer free trading with cash rebates for making and taking.
PAX is the fastest exchange from crypto to Wall Street.
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.
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.
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).
I think maybe we were talking past each other. Yes there is more than one reason.
It's far easier to add capacity by adding sets, as opposed to ways. But they can't add sets in the L1 because of the aliasing problem. When they do increase L1 capacity, if nothing else has changed, then it will be by adding ways.
By your reasoning, no cache should be able to grow, because then their latency would increase too much. But instead, all other CPU caches are growing basically with iso-latency. The reason this is possible is technology scaling. Anyway...
But yes, the L1 does have to be small and fast, but it doesn't have to be that small to be that fast. It has to be that small because of virtual indexing combined with the cost of adding ways breaking other design constraints (possibly a latency constraint, fine). But you could grow the L1 by adding sets and get your required latency.
At a high level it's true that smaller is faster, but it's also true that those L1s could have grown by adding sets (not ways) and achieved the same latency. L2 has grown, but stayed iso-latency. This seems to say that "smaller is faster" does not always hold.
Always impressed that Agner Fog takes the time to publish his results. Pretty amazing. But I think focusing your thinking on the register count in MIPs or the the uarch for some random opcode does not get into the real constraints on L1 cache design at all. One could say that x86 should be even faster, because hey, far less than 32 registers (or historically at least).
My response is like this: yes, the L1 has to be small to be fast, but it has been stuck at 32KB forever now. It could have grown! So it's not as simple as small is fast.
If it was easy to build high performance caches with high associativity, we would certainly see higher associativity. Ideally, you want a fully associative cache, but it's too expensive. In CPU caches, once a set is selected, all N associative ways are compared simultaneously. So growing associativity costs area and power for extra comparators. This growth could cause timing issues, i.e. add latency to the memory access or cause CPU freq. to be lowered.
I had wondered, why are the L1 caches not growing, while L2 and L3 capacities continue to grow: a significant limitation on L1 cache size is actually the fixed tradeoff between associativity, page size (i.e. the 4KB pages allocated by the OS to processes).
Because a 4 KB page has 64 cache lines, then you can have at most 64 cache sets. With an 8 way associative cache this works out to 32 KB. Using 128 sets would cause aliasing, but with 64 sets the cache index is built from the LSBs that just index into the page (i.e. not used in the TLB lookup). Thus, the only way to grow increase L1 capacity is to:
- totally abandon 4KB pages in favor of (e.g.) 2MB pages (not likely)
- increase cache associativity (likely imo)
- stop using virtual index+physical tag (not likely imo)
My point exactly, not the most lucrative. So what remains is the implicit assertion they are fleecing the big time guys. And somehow the big time guys remain in business... so what's going on?
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.