rwem

The air pollution in Pittsburgh isn’t caused by things under the control of the local government or even the state government. It accumulates and blows in from west of there. Only the US federal government can fix it.

I reached the same conclusion but luckily before moving there. Pittsburgh just has bad air. It also has the least sunlight of any American city.

The graph is electric generation only. Electricity accounts for less than 1/3rd of US greenhouse gas emissions.

They’re not steadily falling. As noted in the article, they were up in 2018.

I get the impression from the map of responses that many respondents were taking the piss. Who really thinks Iran is Greenland?

Because we’re all idiots and waited too long, we need to cut emissions by 15% annually, not 2%. 2% does not even offset the increase in US emissions in 2018. 2% is a disaster.

"We need labels that strike at the heart of each issue"

That's pretty much the opposite of the "housing first" approach.

Why do Americans [anything]? Because in short they are ignorant.

Americans lack perspective on virtually all topics. They don't read enough, they don't travel enough, their educations are overwhelmingly technical and occupational at the expense of philosophy and ethics, and their domestic brainwashing apparatus has left them collectively unable to think.

Transportation is just like any other topic American's are unqualified to comment upon, like healthcare. They've been indoctrinated by propaganda campaigns to believe and repeat a series of false statements: their cities are too spread out (they aren't); their cities are exceptionally far apart (they aren't); their weather is somehow unprecedented (it isn't); you can't take groceries/children/lumber home on the bike/bus/tram/train (you obviously can).

So the answer to the headline's question is the obvious one, the one with the most hard evidence and the one with the broadest explanatory powers. The reason Americans believe these things is because of ignorance.

The implementations in the benchmark are all pretty naive. You might get a different outcome with more careful implementations of the functions.

I imagine the downvoting is due to your erroneous projection of the customs of your locale to the entire larger world. Even narrowly considered, your links don’t really support your point of view (eg there are numerous shared pedestrian/bicycle paths in California, children are allowed to cycle on sidewalks in California, etc).

Thank you for sharing the customs of your people and/or jurisdiction.

Guess I'll just stick with the air horn.

The killer application for this technology is a bicycle bell you can use to break the trance of phone-staring pedestrians who are randomly staggering down the pavement.

Yes, and sometimes you want to validate a performance change and you need the release build to run in the benchmark fixture, and then it's irritating that the build takes forever but what can be done? ThinLTO's real benefit is that it uses so much less memory than legacy LTO and can be applied to larger programs (like Chrome).

Everybody should build everything with a reasonable setting of march. Debian Linux still builds everything for K8, a microarchitecture that lacked SSE3, SSE4, AVX, AES, etc. Even building with march=sandybridge seems petty conservative and gives significant speed improvements in many common cases.

ThinLTO was written by people responsible for peak optimization of very large programs at Google. I honestly can’t call it “fast” but it’s a lot faster than GCC LTO. You normally only peak-optimize your release builds so it’s not like developers are sitting there counting the seconds.

Power limits have the same problem, don't they? Except it's maybe worse because you get the product of the error terms for Icc and Vcc?

I wonder how much of this is due to measurement error of temperature. Core frequency and voltage control are governed by some suspiciously round numbers like Tj(max) == 90C. But when the controller thinks Tj == 90C, what's the measurement error?

See that’s the kind of information I want to surface in an interview: candidate thinks C++ doesn’t have random-access iteration. No hire.

SunRay were not Solaris-only. In fact virtually all of the ones that sold were used as Windows terminals.

You'll probably get a lot more benefit from just pulling up powertop and fixing whatever dumb thing is eating your battery. Common issues that are never right by default are PCIe ASPM, SATA ALPM, audio codecs that are always powered, USB devices that are always active, bluetooth spamming away when you're not using it, etc.

Seems to have some control loop deficiencies. If CPU utilization is ~50% then it will enable turbo and utilization will fall below 50% and then it will disable turbo again.

Is this the kind of thing they are asking in interviews these days? I guess it is nice that this author can prove the correctness of their solution, but what's up with that code? Why is what would otherwise be a perfectly good free function instead a member function of a class with no other functions? Why instead of the usual C++ style of a function taking start and end iterators as arguments does this function take a mutable ref to vector<int>? Are these "leetcode" idioms? Does this site just exist to poison the minds of young developers?

If you only have 4 threads it is likely that all your CPUs are sharing caches and you won't see the real downside of the spinlock. They don't really fall apart until you have several sockets.

That's still unreasonably high, isn't it? Even a Go sync.Mutex, not exactly a hot-rod implementation, can be acquired and released in < 50ns on the garbage hardware I have before me.

That’s what virtually all battle-hardened lock libraries do: spin for a bit (but not too tightly, using a pause in the loop) then fall back to waiter lists and futex.

It doesn’t flush the entire cache (that would be a disaster) but it does shoot down the cache line containing the lock in all cores other than the one that acquired the lock.

The real issue with spin locks is fairness. There’s no assurance that any given thread will ever make progress. A thread could starve forever. Production-ready mutexes like absl::Mutex make efforts toward fairness, even if they don’t have hard guarantees.

It’s basically impossible. Unpowered hub motors drag a lot. Unpowered mid-drives are better because they have clutches or freewheels, but you’re still pedaling a fifty-pound bike. Some ebikes do have regeneration triggered by brake lever switches but it’s pretty rare. Others have a regeneration mode switch. Most just don’t bother.

What you should understand about these bikes is the power delivered by the motor, and the power needed to recharge batteries in a useful time frame, greatly exceeds the continuous power a human would normally exert on the pedals.