PathOfEclipse

How many Python JIT experiments have failed? I find it interesting because Ruby is probably harder to optimize than Python but Ruby has had a JIT for a long time. Maybe base python is more optimized than base Ruby so the JIT is incrementally not changing much? Also, I'd expect javascript to be harder to optimize but it has JITs. That could just be a funding issue, though. There's probably much more money and incentive to optimize Javascript.

Almost 20 years ago I helped our company choose between Git and Mercurial as the replacement for Subversion. Unfortunately, I helped them make the wrong choice, Mercurial.

I say wrong because clearly Git won the war and I haven't used Mercurial since then. However, I still think I made the right choice from a technical perspective; I thought Mercurial was way more user-friendly while providing all the features and performance needed. But I guess I couldn't read the future in terms of which one would win out!

My experience profiling is that I/O wait is never the problem. However, the app may actually be spending most of it's CPU time interacting with database. In general, networks have gotten so fast relative to CPU that the CPU cost of marshalling or serializing data across a protocol ends up being the limiting factor. I got a major speedup once just by updating the JSON serialization library an app used.

It takes an incredible lack of awareness or intellectual honesty to hold Fox news to this standard, but not CNN, MSNBC, NBC, CBS, and ABC, or, if we include print media, the NYT, the Washington Post, the Guardian, Reuters, AP, Axios, LA Times, and the Atlantic.

It sounds to me like you're just nitpicking his words. I can't find this quote anywhere, but he's probably saying Wikipedia is taking "stances", to use your word, on subjects where it should instead be trying harder to be neutral and provide multiple perspectives in a balanced manner. Sincerely trying to understand and convey the perspectives of two opposing sides looks vastly different from taking one side, amplifying their talking points, and suppressing or refuting those of the other side.

The counter-arguments to all this all tend to boil down to some form of condescending tone or moralizing:

* left-leaning is just reality-leaning. LoLoLoL right-wingers are sooo stupid!

* Wikipedia should take the left-leaning stance because it is good, moral, noble, and righteous, while the right-leaning stance is vile, evil, unconscionable, and despicable.

If either of those thoughts cross your mind, then, congratulations, you are left-biased. You should try your hand at Wikipedia article editing. I'm sure they'll love you.

I think it was always a mistake to pretend hyperthreading doubles your core count. I always assumed it was just due to laziness; the operating system treats a hyperthreaded core as two "virtual cores" and schedules as two cores, so then every other piece of tooling sees double the number of actual cores. There's no good reason I know of that a CPU utilization tool shouldn't use real cores when calculating percentages. But, maybe that's hard to do given how the OS implements hyperthreading.

.NET perf can be great in the sense that it provides more tools to write C-like code while still taking advantage of safe memory management, as compared to Java. On the downside, both their JIT and their GC seem to be far less sophisticated than the JVM.

Why, for instance, does the CLR GC not have something like TLABs? The result is that it seems like .NET devs have to worry a lot more about the expense of small, short-lived allocations, while in Java these things are much cheaper.

Overall, I think it's easier to program idiomatically in Java and get decent performance out-of-the-box, while C# may provide more opportunities for optimization without having to rely on something equivalent to sun.misc.Unsafe and offheap allocations.

I have no problem with you preferring .NET to Java, and I apologize that my first-cited article was not the best one to share to describe the problem (I should have read it more carefully first), but if you had responded with something like:

"Your deadlock scenario is related to synchronization contexts and can be avoided by ..."

rather than:

"You clearly don't know what you're talking about (but I won't bother telling you why)"

Then we could have had a much more productive and pleasant conversation. I would have responded with:

"Sorry, that article wasn't the right one to share. Here is a better one. The issue I am talking about isn't synchronization context-related at all. It's actually much more insidious."

> For example, starting with .NET 6 there is a pure C# threadpool implementation that acts differently under problematic scenarios.

We're seeing this issue entirely in .NET core. We started on .NET 6, are currently on .NET 8, and will likely migrate to 10 soon after it is released. It's again worth mentioning that you provide zero evidence that .NET 6 solves this problem in any way. Although, as we will see below, it seems like you don't even understand the problem!

> I'm certain you're basing this off of your personal experience from more than a decade ago of some forsaken codebase written in an especially sloppy way.

No, I'm referring to code written recently, at the job I work at now, at which I've been involved in discussions about, and implementations of, workarounds for the issue.

> Moreover, there isn't a single mention that the real way to get into actual deadlock situation is when dealing with applications enriched with synchronization context.

100% false. This deadlock issue has nothing to do with synchronization contexts. Please actually read the 2020 article I linked as it explains the issue much better.

> Pathetic attempt at strawman.

I realize responding to this is to just fight pettiness with more pettiness, but I can't resist. You should probably look up the definition of a strawman argument since you are using the word incorrectly.