std_throwaway

True, they compared a lot - but exclusively under Linux.

Anandtech did a benchmark but that had a flaw in the way they measured the time. Many other benchmarks are with unpatched OS versions to keep comparability. It's not easy to judge when they don't explicitly investigate that effect.

To my knowledge the achievable IPC gains for a single thread are limited. Therefore it can be assumed that other players catch up in figures of IPC while the market leader kind of gets stuck with only a tiny advantage.

What is the alternative?

Expert systems with a myriad of rules that fail the moment they get an input that was not considered?

It strikes me as a term where everybody thinks they know what it means but if you drill down most people just made up their own definition and there's no agreed-upon definition.

While everybody agrees that toxic users are bad and you probably should get rid of them, many would really disagree on who the toxic users actually are.

My made-up-on-the-spot definition would be: "Everybody who hinders business interests."

May it be by hindering user growth or even causing user loss. For example making large groups of users feeling uneasy in some way. For example using bad words or posting bad ideas or even purposefully provoking users or user groups.

Or by hindering revenue streams for example by advocating ad-blockers or making the advertisers or other money sources feeling uneasy.

Or other reasons.

What does "toxic user" mean in this context? How do they differ from a "non-toxic" user?

Does this mean that, with a DIMM-to-LAN interface and cloud storage backing, one could literally download more RAM from the internet?

Is there a known probability curve?

With so many actors it could be very steep. Like 51% capacity has 99% chance of success and 49% has 1% of success and 40% has practically zero chance (these are made up numbers).

It could also be quite shallow as in 1% capacity gives you 1% of success... that would actually be quite bad and invite malicious actors to test the system with regular attacks.

I see, the number in the name is not to be taken too literally.

OK, so by 51% you really mean at least 50%. Do you happen to have a background in finance? It's quite unusual to say 51% in math/engineering.

In order to get to 51% share you would need 104% of the current hashing rate. Did you consider that?

This is both, correct, and useless.

Do you rather feel that Reddit has gotten worse or did you grow out of it?

I feel like me or the web has changed significantly over the past years. I'm just not sure if I'm different and have seen it all or if everything became more professional and commercial and at the same time less interesting to explore.

This doesn't even make sense. Why would they keep a behavior that could be considered a bug when creating a new instruction set?

> I suspect most carbon that passes through a cow is exhaled as carbon dioxide.

That would mean that the cow gets higher nutritional value and can needs less food.

Is this also affecting code in 64 bit mode?

I don't consider removing superfluous features a bad thing as long as the core features are working flawlessly.

EDIT: Apparently they removed really useful features which is a bad development.

To be fair, if you just mess with the registry and corrupt it, you should expect weird problems.

Wouldn't a central proxy service as fallback be enough then?

I don't understand how software can get this much worse. Having done absolutely nothing would have left Skype in a better shape than what we have now.

What did they do with it? Do they not regression test? Are they letting each new intern add a new feature while nobody really cares about quality? Did they just replace the old software with a new bug-riddled software that's getting pushed out the door without quality checks? Is it some manager trying to earn a medal by using that new MS-framework to rebuild everything and needing to push it out fast to declare success and move up while leaving the ruins behind?

Does the methane get released after the cow has finished digestion and the manure is left to rot? The carbon has to go somewhere if it's not turned into methane inside the cow.

PyQt is not PySide. Qt (the foundation) does not officially support PyQt. PySide (the old one) did not support Qt5. PySide2 does support Qt5.

This seems to be the successor for PySide that supports Qt 5. The old PySide died some years ago and only PyQt was offering Qt 5 support. Due to some details PyQt was never officially supported by Qt. Is PySide2 now officially supported by Qt?

So you're basically building a distributed application just because you can't share memory properly. This can be very efficient if little communication is involved or a total nightmare if you have gigabytes of data where you need lots of random read access to walk the data structures at high speed. If you're not careful you spend most of your time pickling and unpickling the stuff you send over your pipes while requiring duplication of your gigabyte data structures in order to gain at least some parallelism.

I don't see a way around this mess with the current structure of python. You would have to reimplement the data heavy part completely in another language that provides proper threading models.

Thanks, I will try that!

When was the last time you've tried it?

Can't you use CPython for development and Nuitka for deployment?

It was around 150..300 MB if I remember right. Admittedly, I do import a lot of modules. Program startup for me is in the seconds, not milliseconds. I maybe could cut it down 50% or even 80% but then that would cost a few weeks or a few months. Having a quick and robust solution to be implemented in a single week to cut down startup times by that amount would be highly preferable.

> The GIL is an implementation detail, not poor language design.

As I understood the GIL simplifies data structures by removing any regard for concurrent access.

If you remove the GIL you must move your synchronization (mutexes) into the data structures and immediately get a big performance penalty.

If you wanted to avoid this overhead you run into swamplands where the programmer must take care of concurrent access patterns and everything. Also many CPython modules would stop working because they assume the GIL.

It can be done but last time I read about the GILectomy there was no clear way forward.

The GIL is a pretty nasty problem once you try to scale things beyond one core.

Simply try something like unpickling a 10 GB data structure while keeping your GUI in the main thread responsive. You cannot do that because the GIL locks up everything while modifying data structures. Move the data to another process instead of another thread. Great, your GUI is responsive but you can't access the data from the main thread.

You can say that such a humongous data structure is wrong or that a GUI isn't meant to be responsive or programmed in Python or that I'm holding it wrong. Probably right.