I'm not anti nuclear or anything like that. It's just the financial comparison one has to make. Currently competing with solar + batteries is hard since unlike SMRs which hypothetically will get cheaper, they are getting cheaper at a quick rate and don't have the history of cost overruns that nuclear does.
I understand. My point simply is that the relevant price comparison is nuclear versus solar + enough batteries to make the solar plant equivalent to a nuclear plant. The battery system is the lynchpin of efforts to substitute solar for nuclear, and the cost/timeline of that should be factored in. But usually we just see an apples-to-oranges comparison of nuclear by itself and solar by itself.
4 hours at full tilt is pretty good, assuming that for the same volume you can store double the power in the next 15 years that means that you can replace those cells at end of service life and end up with 8 years ect.
> How many times do you have to fully replace the panels in that timeframe?
3 times, assuming current panel lifetimes. The panels will be even cheaper by then and will likely be robotically installed.
> How many times the batteries?
Maybe 4 times? Same as the panels; they'll be cheaper and easier to replace.
Maintaining and upgrading nuclear plants also has a cost. They don't last 100 years for free.
> And what about seasonal storage?
Might be unnecessary with enough overbuilding and grid interconnections. Or there might be cheaper storage technologies. Or batteries might become cheap enough that fewer duty cycles for season storage become economical.
> How many times do you have to fully replace the panels in that timeframe?
You don't have to replace them. After 30 years the panels will still be producing >80% of their initial output.
Of course it might be economical to replace them with newer panels, since solar tech is getting better every year. 30 years ago solar cost roughly $8/W of peak capacity (adjusted for inflation), and today were somewhere around $0.1 to $0.3 per watt. Assuming $0.25, that's a 32x increase.
Imagine in 30 years we replace them with solar panels 32x as cost-effective as today's (and same for batteries, whatever the factor might be). How competitive does the nuclear plant look?
LLVM has range flags and things like nnan that could in theory be used to replace a minimum intrinsic into a minimumnum (iirc x86 has a instruction for the latter but not the former) https://llvm.org/docs/LangRef.html#floating-point-min-max-in... I'm not sure if the optimizations use this but in theory they could
We are slowly moving on replacing this stuff with implementations written in pure julia.
Currently the femtolisp parser is only used during bootstrapping the core systems so that we can parse the pure-julia parser and then we switch over to the julia parser. The same process is now happening with the femtolisp implementation of the lowering pass.
My night and weekend project the last month or so has been creating and implementing a package that provides a pure s-exp syntax for Julia that lowers to Julia's AST directly, and lately been churning through (mostly Opus is doing the actual churning) all the problems of creating an automatic transpiler for Julia to this other syntax.
Not ready to share just yet but nearly at the point that there are no Julia-syntax fallbacks in the entire base/stdlib and a femtolisp parser for the sexp syntax is able to build a complete Julia sysimage from the transpiled files. Already verified that I can transpile the .jl source of the Julia package for the syntax into the syntax, then use that transpiler to transpile again and load into the running sexp repl, then use that transpiler on the source again and get byte identical code, and along the way am testing to ensure that the entire Julia test suite passes in the sysimage being built.
So, with any luck here soon I'll have a sexp syntax for Julia that builds from raw transpiled sexp-syntax source and uses sexp syntax natively in the repl but can transpile & load any Julia code. Fingers crossed.
I'm aware of --lisp but it's not very good imo lol.
I agree. Was trying a tongue in cheek comment about how the Julia/LISP discussion over the years often would have someone point to julia --lisp as an argument for Julia being a LISP dialect.
Chaos mode is an option when invoking rr that can expose some concurrency issues. Basically it switches which thread is executing a bunch to try and simulate multiple cores executing. It has found some race conditions for me but it’s of course limited
Unfortunately that only works for large-scale races, and not, say, one instruction interleaving with another one on another thread without proper synchronization. -fsanitize=thread probably works for that though (and of course you could then combine said sanitizer with rr to some effect probably).
One option would be to combine chaos mode with a dynamic race detector to try to focus chaos mode on specific fine-grained races. Someone should try that as a research project. Not really the same thing as rr + TSAN.
There's still the fundamental limitation that rr won't help you with weak memory orderings.
I havent tried Tsan with rr but msan and asan work quite well with it (it’s quite slow when doing this) but seeing the sanitizer trigger then following back what caused it to trigger is very useful.
Yeah, the reason it only works for these coarser race conditions is that RR only has one thread executing at a time. Chaos mode randomizes the durations of time allotted to each thread before it is preempted. This may be out of date. I believe I read it in the Extended Technical Report from 2017: https://arxiv.org/pdf/1705.05937
There is, it's called count_ones. Though I wouldn't be surprised if LLVM could maybe optimize some of these loops into a popcnt, but I'm sure it would be brittle
So it was a bit more pervasive than this, the issue was that flushing subnormals (values very close to 0) to 0 is a register that gets set, so if a library is built with the fastmath flags and it gets loaded, it sets the register, causing the whole process to flush it's subnormals. i.e https://github.com/llvm/llvm-project/issues/57589
btw, there has been a pretty nice effort of reimplementing the tidyverse in julia with https://github.com/TidierOrg/Tidier.jl and it seems to be quite nice to work with, if you were missing that from R at least
LLVMs API is the c++ one. The C one while more stable also doesn't support everything. Keeping up with LLVM is annoying but it's not the source of bugs or anything of the sort. PS(it's not actually stable. Because if the c++ code it calls is removed it just gets removed from the C one)
I say this as one of the devs that usually do the work of keeping up the latest LLVM.
