The Royal United Services Institute (RUSI) has an updated tally on defensive and offensive munition expenditures. It's likely not 100% accurate due to the sensitive nature of those figures.
> 11,294 munitions in the first 16 days of the conflict, at a cost of approximately $26 billion.
Incidentally, $26B is a sum in the same ballpark as the cost of eradicating homelessness in the US, ending large-scale hunger worldwide or making significant progress towards safe drinking water for all or the eradication of malaria.
Author here. The $75M is specifically for Ground Based Interceptors (GBIs). This is the U.S.'s ICBM mid-course interceptor. There are other interceptor types in the current U.S. arsenal:
Patriot PAC-3 (~$4M): Nations burnt through 600-800 in the first few days of Operation Epic Fury. There are reports that they're being used for drone defense.
SM-3 (~$10-30M): Ship-launched
SM-6 (~$4-5M): Ship-launched
THAAD (~$12-15M): Terminal phase, high altitude
GBI (~$75M): intended for interception of ICBMs (reported as the hardest type of missile to intercept)
Each type of interceptor is optimal for certain type of threats, which is yet another constraint on the optimization problem.
The recently announced "Golden Dome" project intends to get around this issue by putting a vast constellation of satellites into orbit. Each satellite would likely need a serious source of power in order to use its laser. Assuming that's just an engineering problem, then the issue becomes coverage. That is, depending on the adversary's capabilities, you'd need an absolutely massive constellation in orbit [0].
This is such an insane plan, and I don't mean that in a good way.
For one thing, it can do little to nothing about low flying nuclear tipped cruise missiles, especially in less than ideal weather. These already exist, so the Golden Dome system is already inadequate on day one.
> For ICBMs, one idea was to use orbital, nuclear powered lasers to hit the missile on the boost phase.
Author here. Thank you for your insight.
I took some time to read about the recently proposed "Golden Dome" defense system, and what you laid out seems to be the end goal [0]. It's difficult to tell how realistic this actually is. The size of the constellation of satellites needed seems prohibitive, to say the least.
That's also great for letting the compiler unlock auto-vectorization opportunities without delving into the world of manual SIMD.
Even storing something simple such as an array of complex numbers as a structure of arrays (SoA) rather than an array of structures (AoS) can unlock a lot of optimizations. For example, less permutes/shuffles and more arithmetic instructions.
Depending on how many fields you actually need when you iterate over the data, you prevent cache pollution as well.
One of the authors of PhastFT here. Thank you for your interest.
We went out of our way to configure FFTW for AVX-512. The Rust bindings don't do it, but the FFTW itself in the benchmark does.
It's worth noting that with FFTW you have to choose between building it for your CPU and making it non-portable, or targeting the lowest common denominator of CPU features so that it runs everywhere but much slower. Meanwhile PhastFT detects the available CPU features at runtime, and will utilize the fastest CPU features without sacrificing portability.
Lastly, we are currently working on support for interleaved format [1]. That should ship in the next release.
FFTW will definitely query cpuid at runtime too, since it's piecing together kernels anyways it's not much more work for it to choose to ignore AVX, etc. If you use the [guru interface](https://www.fftw.org/fftw3_doc/Guru-vector-and-transform-siz...) to configure it to work with split arrays (and maybe use FFTW_MEASURE when planning) I think the benchmarks will be a lot more 1:1
> 11,294 munitions in the first 16 days of the conflict, at a cost of approximately $26 billion.
Several detailed tables are in the link below.
https://www.rusi.org/explore-our-research/publications/comme...
reply