Venezuelan oil production has declined by about half since Chavez took power. Given the losses they suffered from expropriation, the oil majors aren't particularly keen on returning to Venezuela without stronger guarantees, and oil executives aren't idiot--they understand that Trump is not a reliable partner and that there's a good chance that any deal he strikes with Venezuela will fail to be honored past 2028 (or possibly even before then).
There's also the fact that Venezuelan crude oil is basically among the worst grades of crude oil, the sort of stuff that the refineries don't want to use unless they have no other options. Which also means that as global oil demand hits its maximum (likely within decades), this is also going to be some of the first oil production to be permanently mothballed. With massive necessary investment to get anything running, subpar product, and a very uncertain political situation for the necessary long-term investment, most oil companies are reluctant to invest.
As a result, the only major oil company to have really been contemplating investing in Venezuela is Chevron (which itself appears to be mostly hedging its bets); Trump more recently announced another deal with a supposed major investment in an unnamed operator to extract oil from Venezuela, but without any companies being named, I'm skeptical of how real it is as opposed to merely being a vehicle for graft.
As AnimalMuppet says, if anything does get built, it's on the order of years before anything starts flowing.
I can't read the article either, but my understanding of the various factors is this:
* Houthis have taken control of all of the Yemeni coastline along the Bab-el-Mandeb Strait (and an island in the middle of it), which gives them the ability to effectively interdict trade through the Red Sea and the Suez Canal, just as Iran has shut down the Strait of Hormuz.
* Not that it matters that much, because the Saudi pipeline that lets it export crude via Yanbu, in the Red Sea, has been disabled, and current estimates suggest that the recovery time is in weeks-to-months. That's about 4-5mbpd of crude oil that's down for the near feature, or about 4% of global crude oil production.
* Now that the summer driving season is over, US refineries are starting to switch from summer blends to winter blends, and this is one of the periods that refineries go down for maintenance. So US refinery capacity is down.
* The supply shock has been mitigated for the past several months by drawing down reserves (note that reserves were relatively high when the war started). This includes both national strategic petroleum reserves, but also corporate reserves (e.g., tanks on-site at refineries). It seems some of these reserves are starting to hit effective 0.
* On top of this, Trump is making it more and more clear that he has no intention of actually doing anything to end to the crisis. For example, he's effectively said that he's not going to do anything before the midterm elections, two months away. Which means the market optimism that the war is going to be over, like, tomorrow is fading.
I've seen two theories as to what's going on. One is the theory you've espoused, that AI companies are trying to do regulatory capture. The other theory is that they're starting to worry about running out of cash, so they want to do a Washington Naval Treaty-style pause to lower the amount of money they have to shovel at model development to stay competitive.
These theories aren't entirely incompatible with each other, so both could be true at the same time.
> I've seen two theories as to what's going on. One is the theory you've espoused
This theory is just what the AI firms have concretely asked for from government and described themselves as doing voluntarily in the same documents to which people have attributed a commitment to a slowdown based on the titles and non-concrete framing verbiage.
> The other theory is that they're starting to worry about running out of cash, so they want to do a Washington Naval Treaty-style pause to lower the amount of money they have to shovel at model development to stay competitive.
That’s not really a different theory as to what they are trying to do, it’s just an explanation that goes one step further as to why they want the government to step in to protect them from outside competition while also allowing them to gorm an agreement not to compete to reduce internal competition in the existing oligopoly.
The main alternative explanation at the same level is that they are seeing growing threats from good enough foreign/minor-lab/open models, and want to lock in marketshare by excluding competitors, and maybe that’s what you read as implied in my post such that the “running out of money” would be an alternative, and if so you are correct that while they are alternatives, they are not at all mutually exclusive: both can be true (and the emergent competition could partially explain investment drying up, and vice versa via reduced funding making it harder to stay ahead.)
> But for a compiler to target, it's just so painful. It's so different from almost all other ways CPUs work. There's a reason both CPU and compilers prefer to avoid x87 when possible and use regular SIMD (SSE/AVX) instead.
The x87 ISA is essentially a one-address stack-based ISA (so unlike a pure stack ISA, you can reference another value on the stack without having to introduce something like a dup instruction). Which honestly isn't particularly painful to work with for a compiler; it's not usual, but there are other ISAs that are also stack-based (the JVM bytecode is the one that most immediately comes to mind).
The actual weirdness of x87, what makes all the compilers run away from it, is that the only values you can have on the stack are 80-bit extended-precision types. But people don't use those types in their code, they use 32-bit and 64-bit single and double precision, and compilers largely implemented these types by pretending that the x87 just used those value sizes in the first type (the only ones to actually get it correct that I'm aware of are Java's strictfp and Intel's icc, although the latter is merely just correctly implementing FLT_EVAL_METHOD==2). The end result is that compilers caused code to have essentially random and largely uncontrollable precision changes, which pissed a lot of users off, and the SSE units having regular scalar proper single and double precision types made it easier for compilers to switch to that rather than introducing the proper sequences to compile for x87.
There is a significant difference between a stack-based ISA and a stack-based bytecode. In bytecode, it's fine or even a requirement to empty the stack between loop iterations. The JIT will then enregister variables across the loop as appropriate.
With x87, however, that causes extra overhead from loads and stores that's best avoided. Unused stack space can be used to cache frequently used variables, but as operations must use ST(0) as one parameter, FXCH instructions must be used to swap around variables. Matching the x87 stack state on entry and exit of the loop is tricky and compilers historically have had trouble doing it. Different FPUs also differed on the efficiency of FXCH so there were often situations where a particular arrangement would double the speed of a routine on one CPU model and halve it on another.
Not to mention the size difference as well. The JVM stack is 2^16 in size while x87 has 8.
The java compiler can practically pretend like the stack is infinite in size while a compiler dealing with x87 has to contend with spillage in all but the most trivial of algorithms.
> Elsewhere on HA you’ll find my extended rant about how strange it is that we don't have a language that elegantly abstracts computation over threads, SIMD, GPUs etc. Compilers can do this sort of thing now, just not optimally.
Autoparallelization has been a hot topic for literally decades, quite possibly longer than you've been alive.
The problem is that the techniques you need to do to write good SIMD code versus good GPU code versus good multithreaded code versus distributed computation are all different. Taking just memory concerns: a SIMD code needs you to carefully arrange memory so that every thread is accessing an adjacent memory location. GPU code likes locality, but you have large group sizes that can share all the local memory pretty cheaply, and loading from global memory to local memory is relatively expensive, so now you have to do a lot of tuned blocking. With multithreaded code, you now want to avoid sharing between different threads (which generally requires distributing loop iterations among threads very differently). And with a distributed platform, now you're primarily worrying about the overhead of communication of data between different nodes, and you're trying to minimize that.
Another axis: a GPU wants you to load a large batch of work and then start it - you can't be bouncing between CPU and GPU work all the time, but you can mix SIMD and non-SIMD instructions freely.
It doesn't seem to me like you've described concepts that are all that different, loading from global memory is slow on the CPU too because often it requires some kind of barrier or lock. All techniques require you to pre-arrange memory, just in different sized blocks. And sharing data between "lanes" is always to be minimized. Different amount on different platforms ofc, but the ideas seem similar.
There is better than even odds I'm older than you, so I'd recommend you rethink using phrases like "possibly longer than you've been alive", it's not ... polite regardless of people's age.
The point (and I'd encourage you to find that thread to not retread ground) is that we absolutely can compile most computation heavy code for these different targets reasonably well - what we cannot garentee is that the resulting code is optimal given context. But gosh we can do so much - I’d encourage you to look into in profile guided, target aware, and autotuning optimization etc. (and then of course, there are LLM guided optimizations, but that's a whole other kettle of fish)
VLCCs are too large to fit through the Suez Canal. I don't know how much of Saudi export is using VLCCs versus Suezmax or smaller tankers, but I've heard that much of the Red Sea oil export is currently going through Bab al-Mandab, not that I have a source on hand.
See, e.g., Barak Ravid regularly reporting in Axios the impending ceasefire negotiation progress in the Iran War, which largely have failed to come to pass.
As a point of evidence in favor of this viewpoint:
Multi-dozen car pileups aren't particularly rare, with the common cause for a lot of these being "one car hits an icy patch, hits another car, car behind them tries but fails to stop in time due to the ice, rinse and repeat a few dozen times". And the root cause of that is every single driver in that collision driving too fast for conditions and unable to make the requisite emergency stop in time.
In my callow youth I was responsible for a couple of fender benders and the cause was always a highly imperfect understanding of the appropriate stopping distance of my car. This obviously gets worse, the worse the conditions are. My Tesla never makes this kind of mistake.
Yes, it does. The lambda still needs to follow the C++ object model in case someone might use it like a regular C++ object. It's possible to change the ABI with escape analysis that proves you know all of the uses of the lambda to change the ABI, but a) that escape analysis is surprisingly easily defeated [1] and b) ABI-changing optimizations tend to be much more common in research papers than production compilers because getting them right on real code is a lot more difficult than it looks.
[1] The lambda function probably has the same linkage as the function the lambda is contained in, which likely isn't "the only copy of this function is in this TU" but rather "this function may appear in several TUs, but all of these copies are equivalent and you can pick whichever one you like as the actual body." Very different opportunities there!
reply