And yet no thought is given to broadcasting a thought to thousands or millions of people simultaneously. You're right, by the way, nobody should be put on trial for minor transgressions like this, but in a humane world, they wouldn't happen either.
also, FTA, it appears they did ask for an apology, which they apparently didn't get. Another thing interactions on the internet make very hard, is that owning your transgressions when you're wrong has very little utility as the other person is easy to objectify.
I see that Steve Klabnik an Corey Haines apologized on their blogs, and you're right that I was wrong there. The reason I wrote that was in the article it says "I queried some tweeters for more information on why exactly it was so bothersome. I didn’t get apologies from these tweeters."
I do want to point out that if you complain about someone in a medium, it's reasonable to expect the apology or explanation there. If someone is a jerk in front of other people to you, they should clarify their behavior in front of everyone, not just a direct, personal apology.
This is kind of my point - I'm not a neurologist or social scientist, but, in my opinion, we humans don't seem well equipped to deal with the group sizes the internet makes available. I think it's totally valid to point out that the problem here isn't really the individual behavior per-se, it's the behavior in the context of 10k others. In the blink of an eye, we've made it possible for virtually everyone to reach an enormous amount of people, so easily, and with so little oversight, that it falls on those people to take responsibility for engaging with the platform in the first place.
If it's reasonable for a 12yo to be able to play in a for-money tourney, then I don't think it's unreasonable to think they should know the difference between right and wrong.
As a parent of a now 13 year old - it is not reasonable for a 12 year old to play a for money tournament. 12 year olds may "know right from wrong" in some sense, but they do not have adult brains. Expecting them to make decisions like an adult, or understand "right and wrong" the same way an adult does, is ludicrous.
Then why should they be able to win money off adults?
Classic "have your cake and eat it too". If you want to play in tournaments with adult prizes then you should expect adult consequences for misbehavior.
They shouldn't be able to. But either way, kids don't have adult brains, and there's nothing anyone can do about that. They are physically different. You can't expect a 12 year old to dunk a basketball, and you can't expect a 12 year old to think like an adult.
These are synthetic benchmarks but it's quite significant in them.
From a different tweet:
> It's the total time for 32 threads each doing 10'000 lock+unlocks (on a 64C/128T threadripper). So, the numbers you quoted correspond to a lock+unlock operation going from 8.75ns to 2.45ns, under low contention.
> The numbers can vary a lot in different situations/hardware though.
I think the focus is on the synchronization and implementation choice based performance differences, https://twitter.com/m_ou_se/status/1526211117651050497 which are not super easy to characterize but come from much more than just removing an allocation.
> you're often going to be better off eliminating the Arc/Mutex anyway
Not always. Mutexes can be really fast (10-20ns), especially since they often optimistically spin, and Arc in Rust is (often) relatively low cost since you can hand out "free" refs without touching the atomic.
If removing the Arc/Mutex would require allocations the Arc/Mutex could easily be faster.
Notably, still worse than 0 ns. Ditto for Arc's refcounting and additional allocation. I'm not saying go on a crusade against Arc+Mutex here, but the easiest way to make effective use of modern multicore CPUS is to go to shared-nothing, independent data-per-thread designs (obviating Arc+Mutex). And if you aren't using Arc+Mutex, it's harder to accidentally share mutable state between threads.
I just think people seriously overestimate the cost of a mutex when implemented efficiently. Unlocking a mutex can be ~10-20x faster than fetching a value from main memory, or just a bit slower than a few integer operations. The way people talk about mutex operations you'd think that it's akin to hitting disk when it's actually a few orders of magnitude closer to hitting your L2 cache.
It gets a lot more expensive if you’re actually contending the mutex between threads; and if you’re not, why use a mutex? I agree the uncontended case is fast — it’s just not very useful.
There are a lot of scenarios where you're rarely contended but you cannot rule it out, so for correctness reasons you should use mutual exclusion but your measured performance in the real world essentially never cares about the contended case.
Modern fast mutexes are perfect for that, because their uncontended case is so good. This also inculcates the correct choice for the programmer, you should prefer to write code that is less often contended, not fight hard to get better contended performance at a cost of worse uncontended performance. Contention is bad even if your mutual exclusion primitive performs well.
But Mara measured across simulated workloads with varying contention and this fix improves them all to different extents.
Because it's an incredibly efficient, safe option for doing so. Lots of shared state is rarely contended. For example, imagine you have a 'Config' that gets updated periodically in the background, readers of that config only check for updates every 1 second, and you have 7 parallel readers (and 1 writer for an 8 core system).
A Mutex is a trivial way to solve that problem that will be extremely efficient.
Don't atomic operations trigger cache synchronisation in CPUs? Doesn't that affect performance negatively? That would mean even a non-contended mutex would affect performance negatively. I suspect it depends a lot on the specific workload (and maybe even what addresses data is stored at in memory), so I'd measure the specific case, but that's my a priori gut feeling.
The overhead of atomics is almost (if not entirely?) exclusively with regards to managing the caches in the CPU. Otherwise they're just normal bytes. Your CPU already has to do some cache management with regular bytes, so an atomic is only worse if there's contention (because that forces a flush).
The worst case for an atomic write is two additional cache line flushes, iirc.
In normal conditions you can check for a ZWJ, but with regional coding chars, you would have to consider the regional chars block as a single char in the reversal. Given that is isn't necessarily locale dependant but presentation layer dependant, there might not be anough info to decide how to act.
My suggestion to you is going to sound pithy, but its what worked for me: do problems. Lots and lots of problems.
Pick a direction (maybe discrete math, if you're trying to do CS) and get a book (I like EPP, as it is super accessible) and go, in order, through each chapter. Read, do the example problems, and do EVERY SINGLE PROBLEM in the (sub)chapter section enders.
Its a time commitment, but if you really want to learn it, this is one way to do so. IMO finding the right textbook is key.
I make pseudo-generative work art using a custom cv-based pipeline I built myself. I use redbubble for printing (posters are OK, everything else is mediocre). Check me out at https://zwerdlds.me
It's NOT legally OK. The license permits use of the copyrighted work with certain terms, attribution being one. That term was violated, just as when a big company takes a low level gpl driver and uses it without releasing the source. AI could have rightly been subject to a DMCA takedown, which is a legal action, for example.
also, FTA, it appears they did ask for an apology, which they apparently didn't get. Another thing interactions on the internet make very hard, is that owning your transgressions when you're wrong has very little utility as the other person is easy to objectify.