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
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.
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.
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.
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.
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.
In the same vein, there is the "tournesol"[0] browser extension, which plugs its own recommandation algorithm into YouTube, to promote educational videos
An interesting project, but it seems to be in its infancy :)
I definitely want an actor based language to play with, and something with a strong type system would be perfect. gleam [1] and inko [2] look promising in this regard
fundamentally I think though is that for distributed systems you don't really want actors, you want ~erlang processes. The distinction being around how errors propagate between processes, and various mechanisms to deal with that. The actor model doesn't have any of that in its theoretical basis. Because in a distributed system you fundamentally have unpredictable errors, and generally erlang tries to shoehorn you into a programming style where you're ok with faults, which makes your system more fault tolerant.
The core philosophical problem with gleam is that it is trying to get rid of errors. Ok, well good luck with that.
Actor systems can handle unpredictable errors and if you watch a recent talk by Douglas Crockford about actors/Misty there are Erlang-like "let it crash" examples.
I've been meaning to get to know gleam better, so I'm interested in your comment.
Do you mean that the error handling of an Erlang process is in any way diminished by using gleam? Or is it just that maybe it's unnecessary work to try so hard to prevent errors which you've already put so much into tolerating?
I've nothing to add to the conversation, but I jump on this oportinity to tell you that i like the content you've made with Adam Barth on yt very much, have a great day :)
You are confusing the `go` toolchain and the binaries generated with Go toolchain.
The `go` toolchain itself is compiled statically, this is why this works without issues even in NixOS. Binaries built with the toolchain may or may not be linked against libc depending if you enable or disable CGO. But this is not related to the toolchain, that will work regardless since the toolchain itself is statically compiled.
Edit: or in other words, the `go` toolchain is built with CGO disabled.
Just cause it is a sailing vessel does not mean it does not have an engine.
It probably uses a couple of 100 liters of disel to get in and out of port, driving generators and heating the boat.
On top of that the sails will degrade with time and the ship will need to be repaired and there is allot more crew and manpower needed per unit of cargo.
Everything has environmental cost in CO2 emissions, and the amount of useful work you get from a large container ship per amount CO2 emissions is insane. The only thing that can get you those kinds of numbers is scale.
According to [0], a typical container ship generate 12.5 g of CO2 per ton per km, which means that one trip from France to NY with 350T of cargo would release about 35T of CO2 in the atmosphere.
I'm convinced that this sail boat generates an order of magnitude less of that (I can't find any estimate of it)
Whatever the initial CO2 cost of the construction of this boat is, I'm sure that it's a net benefits if it's used long enough
1.8 is lower than 3g. If those aims are reached I guess they are "more green" than I thought. But the gain is quite small, if you truck that cargo for 160km all the CO2 savings are gone. A modern truck emits 45g of CO2 per km.
It doesn't really make sense to compare a 350T sail boat with a super tanker, a comparable diesel boat produce 36g per ton per km(according to the same report), the "grain de sail II" aims to replace those, and the gains are huge.
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...