About a third of those fires are criminal [0], yes that's a lot, but the majority are still accidental or natural.

Even the criminal ones are only enabled because of the dry vegetation, caused by the recent heat waves. IMO focusing on what caused the spark is missing the root cause: global warming.

And yes you can argue that such fires existed previously, but what's concerning is that the frequency on which they are happening is increasing rapidly

[0]https://observatoire.foret.gouv.fr/themes/les-causes-des-inc...

In the South of France, dry vegetation in summer is normal. Areas where this is most expected, the Mediterranean, have actually seen a decrease of fires over time as preventive measures and fire-fighting readiness have increased. [1] See graph for "Nombre de feux de foret in zone mediterraneene 1973-2024", graph for "surfaces parcourues", and text.

That's why I am suggesting to keep a cool head and to take a step back to analyse things rationally. In any case that is good advice to adapt to warming, too. If you go down the rabbit hole of media reporting you are going to have a nervous breakdown.

[1] https://observatoire.foret.gouv.fr/themes/l-historique-des-f...

A rational approach to existential threats is indeed good advice, but to surrender in the face of complexity is not.

The human induced climate catastrophe is due to a systemic failure and consequentially needs to be addressed on a systemic level. The economic system and policies need to be adapted, even against the implied subjective interests of the biggest holders of capital and assets.

They like to paint that as "impossible", but of course it's not.

Thanks for illustrating my point...

Well, actually, you're exemplifying mine.

Being trapped in an Overton window selected for you by those invested in upholding the status quo is what leads to your emotional stress.

The fundamental disconnect between the existential threat of climate catastrophe and the official un-reaction to it is what leaves you unable to cope with actually very much white-washed reporting on the topic.

Can't you solve it using hash trees (or Merkle trees) ?

You tag each computation nodes with a hash of its dependencies and some constant salt, that gives you an ID which identifies the results that the computation node would produce; before running it.

You can then use those IDs to index the computations results in a cache; whenever you query a computation results, as long as you update the IDs of each leaf of the computation graph, you will only re-compute the nodes that need to be updated

What you're describing is akin to a basic pull-based incremental engine, akin to salsa. The base design is straightforward, but you need some additional logic to avoid following the whole execution tree when hashing. Their downsides is that sometimes you do have to follow the whole execution tree, even if nothing changed.

Push-based designs instead "push" changes to their dependants, which can be quite efficient especially in the case where the update doesn't propagate much. However it has the downside of potentially requiring to update nodes that are no longer used, or updating nodes multiple times.

Could you duplicate `RECORD_INST` before each `INSTRUCTION_N`, so that:

```

   INSTRUCTION_1:
     // subroutine 1
     ip++;
     goto *dispatch_var[*ip];

   INSTRUCTION_2:
     // subroutine 2
     ip++;
     goto *dispatch_var[*ip];

```

becomes: ```

   RECORD_INST_1:
     // record logic
   INSTRUCTION_1:
     // subroutine 1
     ip++;
     goto *dispatch_var[*ip];

   RECORD_INST_2:
     // record logic
   INSTRUCTION_2:
     // subroutine 2
     ip++;
     goto *dispatch_var[*ip];

```

This way you could directly swap `dispatch_var` with an array populated with the `RECORD_INST_*` labels, and remove one step at runtime.

Or maybe this is what you are trying to avoid to reduce the binary size ?

Typically, the inner loop of an interpreter is all about keeping the branch predictor happy and trying to fit in L1 cache as much as possible. So, falling through makes sense. I’m also curious whether a simple check of a flag and a conditional branch (which is highly predictable for a mode flag like whether you’re tracing or not) wouldn’t be faster than one of the indirect branches. That would keep the tracing code out of L1 when not in use (you can locate it in a remote function).

The centralized approach they're using does this without exploding in size. I think what you want would be thread local tables to avoid locks/syncing across threads? Would only help for mt, though.

Writing to a ring buffer and processing in batches should be a relatively big W for everything. You could then filter for repeated instructions to compress, which would lend itself to prefetching the next instruction and buffer with hints. Mixed precision record storage might help too, but you're plucking hairs at that point. Making the sampling adaptive based on the hw profiling counters might eliminate some 'useless' work.

The overhead is already so low that it really should not matter, though. Used to spend a lot of time trying to find wins like this but caches have gotten so large it basically doesn't matter. Even in pathologically memory or io bandwidth bound cases I've found it's usually faster to just run 2 or 4 smaller instances over trying to coordinate all of the threads in a single big one.

This is an intuitive step and I kind of did something similar initially (I simplified the diagram a lot, but it was basically what you are suggesting). However, it slowed down the computed goto interpreter by 6% (though not the tail calling interpreter).

The other comment about interpreters being greatly affected by instruction cache is right. The other problem is that PGO in CPython's test suite could be improved and when you have the full thing as a switch-case and trigger the profiling mode, PGO then mistakenly thinks that the RECORD_INST_X section is hot (when it is clearly not). This causes a pessimization in the interpreter loop leading to the 6% slowdown.

That sounds smart, maybe worth testing, but I think it bloats the instruction cache even when not tracing.