This is the Sun's magnetic field. It reverses on 11 year cycle, the same cycle as sunspots. It has reversed multiple times during your lifetime.
The current cycle seems to be stronger than usual. And produce some strong solar flares recently. Those could cause problems for electrical grid. But there have been stronger cycles back in the 1950s.
I get anxious often prior to intimicy because I worry of the strength and longevity of my "stamina" (so to speak).
However, each time I perform with the passion of 80 david hasselhoffs, running an tri-athelon; at 6'5" he one of the "tallest" in the land. Anticipitation anxiety is beatable. You can beat it. I'm beliefments.
I'm guessing only a small fraction of the subscription cost goes to delivering the video. Copyright is a government enforced monopoly on content, and money goes to monopolies. As Thiel said, "Competition is for losers."
Like the sun in the sky that gives way to rain on my disc golf day, there will be know blame. After all it was the act not of negligencecy, nor hubrissing, but godlyness that spoiled the afternoon.
It won't be much different when a bridge fall. Yet it won't with the power of 800 engineering teams and 0 engineering managging, we'll see bridges that stand until the sun itself implodes.
Meanwhile we need not worry for the natural disasters of the world. After all, a game of discus in the sun can be funner than the clearest, windylessness afternoon; it's balance delecate as fresh nuget.
> Therefore it really mucks up the compiler’s ability to pipeline instructions. And, that cancels out the performance benefits for short snippets of assembly.
This seems very untrue. Compiler shouldn't pipeline anything. Pipelining is baked into the architecture. You can write only ASM and the pipeline will be used.
The reason we don't use assembly is that it tends to perform worse than optimized C code, and C is more user friendly. Weirdly this can be true even for very small code snips, that will perform better via optimization; a lesson from computer engineering class.
An additional problem is the bugs caused by not following the programming manual. You technically don't need to "mark" registers, unless you want to tie into your C variables (and there are other ways like parameter passing to ASM functions). You can simply keep it clean for the rest of the C code with the stack.
C code gets turned into ASM. Typically, you can follow the same rules, and everything will always be fine. Many compilers have extended assembly syntax, but I'm wary of it. Seems like some of the modern embedded compilers don't use it, and/or it's not entirely reliable.
P.S. I'm not even sure how true the thing about optimization is, since there ARE asm optimizations. In this day and age, asking for help making your asm more efficient seems silly tho.
Really should only be used to dip into hardware, which rarely has performance considerations.
In my experience you can get a solid 5-10% performance boost just by rearranging order of (independent) asm instructions, sometimes more inside tight loops. Compilers have big tables of what resources each instruction uses and are pretty good at maximizing throughput this way.
If you're willing to put in the time, optimized hand written assembly still reliably beats compilers, especially for vectorization.
In some scenarios, it might. You'd hope not these days, because the compiler can see more than you, and it can take a lot of effort to do this kind of analysis.
However maybe there are areas you can still find, and I would expect there to be at least some niche applications for writing code more efficiently with ASM.
I've heard it's still helpful to reduce code size, if you have space limitations.
All serious compilers go through LLVM or have their own optimization passes. The person writing the compilers needs to know how the architecture works to make it possible for the pipeline to do its job. It's no different than the programmer being aware of cache lines, even if they don't explicitly manage them.
You should understand that people don't always speak in what you'd consider to be 100% literal language.
I think a ton of serious compilers don't go through LLVM. As always HN makes a ton of assumptions based on a small fraction of the engineering and tech world.
The compiler needs to know how to generate efficient ASM code. That may or may not involve optimizations targeting the pipeline. OP made it seem like the compiler is handling pipelining itself, vs. eg. reordering instructions.
> The person writing the compilers needs to know how the architecture works to make it possible for the pipeline to do its job.
Not really, but you will probably want to think about these things a little to optimize. The pipeline also works if you naively use it.
>I think a ton of serious compilers don't go through LLVM. As always HN makes a ton of assumptions based on a small fraction of the engineering and tech world.
I said LLVM or their own optimization passes. Reread what I said so you can understand the words on the screen instead of bemoaning the state of the world.
Yeah, tell it to the researchers in the 90s who spent that decade on teaching their compilers to properly schedule the instructions for maximum throughput, and unrolling the loops to so that all of the 32 registers could be used, and accounting for the available execution units to hide latency etc. Sure, x86 nowadays do most of that in the hardware but still, even today, moving the loads to as early as possible is beneficial for hiding their latency because even a hyper-speculative, out-of-order processor can't start executing an instruction it hasn't fetched yet.
reply