jabl

As an aside, yes the current trend of huge wheels with super low profile tires is idiotic. Hopefully sanity will prevail at some point.

China has by this point large advantages in industrial ecosystems and modest cost labor, and that the state is willing to make large long-term bets on technologies it sees as important in the future.

It's not insurmountable for 'the West' to claw back some of that manufacturing, including high-tech items like batteries. It will take a large, long-time and very expensive effort, however. But talk is cheap, and largely 'the West' has drunken the neoliberalism kool-aid and is staring at quarterly shareholder value so little gets done.

Heck, some Western government are even in bed with the fossil fuel industry, desperately trying to hold back progress in order to claw a bit more profit out of the industry before the full force of the electric revolution hits.

No, heating only. I'd imagine trying to use them for cooling in the summer would easily lead to condensation and attendant moisture damage.

There is a lot of work to do to reverse the trend of increasingly locked down computing devices, particularly on mobile.

But from scanning through this press release, this seems nothing more than the FSF doubling down on their failed RYF approach, which does absolutely nothing for user freedom. In fact it's a big negative for freedom, as it ties down resources that could be spent doing something useful in doing something completely pointless like putting firmwares in ROM and adding another chip to load the firmware.

The thing is, firmwares are here to stay. And firmwares that can be stored on the filesystem and loaded by the OS during driver initialization increases flexibility and reduces BOM cost. So that's what device manufacturers are going to do, and RYF will not have any effect on that.

> Why not put massive, grid scale batteries “behind the meter” at a nuclear or coal plant to enable continual production but only sell power when prices are high and store power when prices are low?

Even better, if you have a functioning wholesale electricity market, you can put those batteries on the grid and benefit everybody.

'Old school' trash burning can produce quite nasty emissions. Not much of an issue with modern plants that burn at higher temperature and have some amount of flue gas filtering etc. Certainly beats landfilling and producing that same power by burning fossil fuels.

My father replaced oil burning with an air-water heat pump. That is, the heat pump heats water that circulates in the same pipes and radiators that were used previously. Apart from installing the heat pump in the boiler room, no other changes in the house were necessary.

> For those unfamiliar, a tanker truck comes by your house every couple of months and pumps diesel fuel into a tank down cellar

Huh, how un-insulated are those houses really? I grew up in an area with climate slightly colder than New England, and our house was heated with an oil boiler (not literally boiling, it was just warm water circulating in the radiators, not steam). Consumption was about 1000L per year, and the tank was big enough that one fillup per year was enough.

Since replaced with a heat pump, FWIW.

AFAIU GIL is still the default, and no-GIL is a build option, you can't select it at runtime.

The big issue is what about all those C extension modules, some of them might require a lot of changes to work properly in a no-GIL world.

One way to think of SIMT is that instead of vector instructions you have a 'fork' instruction which turns on vector mode where the scalar instructions execute on all the vector lanes. Your SIMT code must then include a 'lane index' variable somewhere (of course e.g. in CUDA it's more complicated with blocks, warps etc etc., but in principle it's just a more detailed way of doing lane indexing) so that all the threads work on different data. There is traditionally a shared program counter (PC) (in reality on GPU's, something like per-warp PC's so you still have multiple PC's), where in case of divergent control flow lanes are masked off (though post-Volta Nvidia HW has per-lane PC's). Then finally when you're done with your parallel algorithm you execute a 'join' instruction which blocks until all the lanes have reached that point, and then turns off all the lanes except one so you're now in scalar mode again.

Now whether this is actually how the hardware operates or whether the compiler in the GPU driver turns the SIMT code into something like SIMD code for the actual HW is another question.

> They just won a significant case in its licensing battle with Arm, securing rights to use Oryon cores in Snapdragon chips.

As an aside, wonder how this will impact Qualcomm's RISC-V plans? They were apparently working on some RISC-V cores, but I wonder whether that was just a play to put pressure on Arm, or are they still planning on bringing those out to market?

(The "Arduino UNO Q" that they're launching now is based on a Cortex A53. One would think if they're serious about RISC-V they would start with this kind of things, as in low-end stuff for tinkerers.)

Well, kind of hard to say anything exhaustive in a quick comment, but roughly advantages:

- POSIX compliant, including dotting the i's. As opposed to, say, NFS which isn't cache coherent.

- performance and scalability. 1 TB/s+ sequential IO to a single file is what you'd expect on a large HPC system these days.

- Metadata performance has gotten a lot better over the past decade or so, beating most(all?) other parallel filesystems.

Downsides:

- Lots of pieces in a Lustre cluster (typically nodes are paired in sort-of active/active HA configs). And lots of cables, switches etc. So a fairly decent chance something breaks every now and then.

- When something breaks, Lustre is weird and different compared to many other filesystems. Tools are rudimentary and different.

To get a feel for what 'life with Lustre' could be, see e.g. various 'site reports' from workshops. E.g. for a couple somewhat recent ones: https://www.eofs.eu/wp-content/uploads/2024/09/cscs_site_rep... and https://www.eofs.eu/wp-content/uploads/2024/09/LAD-24-Luster...

> All you have to do to verify this is to just pop into the same OS and version e.g. Ubuntu 24.04 LTS on each ISA in Docker and run `size` on the contents of `/bin`, `/usr/bin` etc.

(I cheated a bit and used the total size of the binary, as binutils isn't available out of the box in the ubuntu container. But it shouldn't be too different from text+bss+data.)

$ podman run --platform=linux/amd64 ubuntu:latest ls -l /usr/bin | awk '{sum += $5} END {print sum}'

22629493

$ podman run --platform=linux/arm64 ubuntu:latest ls -l /usr/bin | awk '{sum += $5} END {print sum}'

29173962

$ podman run --platform=linux/riscv64 ubuntu:latest ls -l /usr/bin | awk '{sum += $5} END {print sum}'

22677127

One can see that amd64 and riscv64 are actually very close, with in fact a slight edge to amd64. Both are far ahead of arm64 though.

Lustre is big in the HPC/AI training world. Amazing performance and scalability, but not for the faint of heart.

AFAIU it is suspected that many(most?) bombs have hollow cores; if so, they're already "playing geometric games".

Needs a [1991] tag.

Needless to say, in the 34 years since that article was published, a lot has changed. Thanks to massively increased transistor budgets, a more complex decoder with accompanying microcode ROM that might have been a big detriment in 1991 would today be a small speck of dust on the processor floor plan. At the same time, memory access performance hasn't increased to the same extent as compute performance, thus putting a relatively bigger emphasis on code density.

All this being said, RISC "won" in the sense that many RISC principles have become the "standard" principles of designing an ISA. Still, choosing "RISC purity" over code density is arguably the wrong choice. Contemporary high performance RISC architectures (ARMv9, say) are very un-RISC in the sense of having a zillion different instructions, somewhat complex addressing modes, and so forth.

The Cray T3D and T3E used Alpha processors. But it wasn't really shared memory, each node with 1/(2?) CPU's ran it's own lightweight OS kernel. There were some libraries built on top of it (SHMEM) that sort-of made it look a bit like shared memory, but not really. Mostly it was a machine for running MPI applications.

A decade or so later on, they more or less recreated the architecture but this time with 64-bit Opteron CPU's in the form of the 'Red Storm' supercomputer for Sandia. Which then became commercially available as the XT3. And later XT4/5/6.

Are you sure about that? If my memory serves, a lot of the Intel compiler people were transferred from HP? At least in the Fortran world, the Fortran frontend for the Intel compiler traces it's lineage back to DEC Fortran (for VAX and later Alpha) -> Compaq Visual Fortran (for Windows) -> Intel Fortran.

Well, in the sense of Alpha being the first 64-bit Linux port, and thus having to fix a lot of places where "bitness" assumptions had crept into the codebase.

DEC (Compaq?) had some plans to make cheaper Alpha workstations, and while they managed to drive down the price somewhat, the volumes were never there to make them price-competitive with PC's. (See also the Talos Raptor POWER machines..)

Yes. AFAIU the cost of process R&D and building and running leading-edge fabs massively outweigh the cost of CPU architecture R&D. It's just a world of its own largely out the comfort zone of software people, hence we endlessly debate the merits of this or that ISA, or this or that microarchitecture, a bit like the drunkard searching for his keys under the streetlamp.

It's also interesting to note that back then the consensus was that you needed your own in-house fab with tight integration between the fab and CPU design teams to build the highest performance CPU's. Merchant fabs were seen as second-best options for those who didn't need the highest performance or couldn't afford their own in-house fab. Only later did the meteoric rise of TSMC to the top spot on the semiconductor food chain upend that notion.

That 3d file manager was called 'fsn'. Then there is a gtk/Linux port called 'fsv'. I maintain a version updated to gtk+3 at https://github.com/jabl/fsv . Unfortunately life has gotten in the way and I haven't had the time to port to gtk4 nor add some missing features.

$6T is in the ballpark of the costs of the Afghanistan and Gulf War episode II (+subsequent occupation) foreign policy adventures.

> That's... not the way the burden of proof works here. You don't do non-proliferation analysis by only worrying about it after someone has proliferated.

Well, let's put it this way. If you want to create HEU you can either start from natural uranium, which is significantly easier to come by and isn't horribly radioactive. Or then you start from spent fuel, which is under IAEA safeguards (for other reasons), is very radioactive and thus very cumbersome, expensive and slow to deal with. Now which is more likely?

Not saying creating HEU from spent fuel is impossible, it's just a stupid way of going about it, and spent fuel already being covered by IAEA safeguards for other reasons so it's probably also going to be easier to detect such a hypothetical clandestine nuclear program.

> I think if you want to announce that reactors are useless for building bombs you need to provide a cite.

If you read my original response I explicitly mentioned that you need a reactor if you want to create a U233 or Pu based bomb. So I have no idea where you get such a notion from.

> Certainly nuclear non-proliferation work by real professionals does include the existence of a domestic nuclear industry.

True, but again not a point I have argued against.

> That "nobody" is misapplied. Certainly it applies to existing nuclear powers, but that's not the demographic in question.

Oh, interesting! If so, can you provide an example of anyone producing HEU starting from spent fuel?

If you're going for the enriched uranium route to a bomb, nobody is going to start with used nuclear fuel, because dealing with the highly radioactive spent fuel is such a huge PITA.

If you're going for the U233 (from Th) or Pu route, yes then you need a reactor and spent fuel reprocessing. But not enrichment of spent fuel.

Or the evergreen(?) https://web.mit.edu/kerberos/www/dialogue.html

> oligolistic

I meant to write "oligopolistic", of course.

> Yes, and the bottoming steam turbine is 1/3 the size of a steam turbine rated for the full power output so… radical capital cost reduction.

It's a cost reduction, but likely not radical when talking about a nuclear power plant. For a cost breakdown of a nuclear plant see

https://world-nuclear.org/information-library/economic-aspec...

So the "conventional island", which would include the steam turbines, condensers, generators etc. is about 15% of the cost. Reduce that to a 1/3 the size, and cost drops to 5% of the total, a savings of 10%. Probably even not that much, since a steam turbine 1/3 the size probably costs more than 1/3 the cost of a "1/1" size turbine. And then the remaining 2/3 of the power output would have to be generated some other way, so would shift cost somewhere else. Of course, some part of the cost of the nuclear island can be attributed to steam production as well. In any case, all in all I don't see this as making or breaking the economics of a nuclear plant. The issues that cause nuclear plant costs to skyrocket lie elsewhere (and no, just blaming regulations is overly simplifying it as well, though a popular scapegoat).

(I'm not sure, but I suspect what's making coal non-competitive with gas isn't so much the steam turbines, but rather that there's more labor and machinery involved in burning coal than gas, from mining, transportation, pulverizers, and then all kinds of exhaust gas treatment used at least in the civilized world, ash handling etc.)

> It isn’t just the turbine but the heat exchangers, in a PWR the ‘steam generators’ are water-water heat exchangers that are usually larger in volume than the reactor vessel.

Yes, that's true. The BWRX300, which of the current crop of SMR's is probably the one with the most realistic prospects of actually being built somewhere, is a BWR, and the maker claims one reason for the supposedly good economics is that they have spent a lot of effort on minimizing construction cost and equipment needed. We'll see, I guess. I think historically the economics of BWR's vs PWR's is mostly a wash.

> Many LMFBRs had two stages of heat exchangers (sodium-sodium and sodium-water) even larger heat on the water though SuperPhenix has relatively affordable secondary heat exchangers and never had them catch on fire.

The follow-up ASTRID project, which never left the drawing board, used a sodium-air (or might have been nitrogen, to avoid issues with trace contaminants in air since it was all closed cycle anyway?) heat exchanger and Brayton cycle turbomachinery, to avoid any potential issues with sodium and water. I think it was supposed to have slightly lower thermal efficiency than an equivalent steam plant, but maybe somewhat lower capital cost.

> x86 also has flags, which add implicit dependencies between instructions, and must make designer's life harder.

Fortunately flags (or even individual flag bits) can be renamed just like other registers, removing that bottleneck. And some architectures that use flag registers, like aarch64, have additional arithmetic instructions which don't update the flag register.

Using flag registers brings benefits as well. E.g. conditional jump distances can be much larger (e.g. 1 MB in aarch64 vs. 4K in RISC-V).

> Or perhaps AMD will let x86 fade away.

I agree with what you write otherwise, but not this. Why would AMD "let x86 fade away"? They are one of the two oligolistic CPU providers of the x86 ecosystem which is worth zillions. Why should they throw that away in order to become yet another provider of ARM (or RISC-V or whatnot) CPUs? I think that as long as the x86 market remains healthy, and AMD is in a position to compete in that market, they will continue doing so.