user5994461

> I'm a bit confused by these claims about the GIL? The expensive IO operations release the GIL.

FYI: The extraction of files is largely python code that doesn't release the GIL. (cf. the zipfile class from the python interpreter has large layers of abstraction with a massive overhead in python code).

Regardless, python packages are thousands of tiny files, so pip never gets to release the GIL for any meaningful duration.

If you were writing an app that only extracted large GB files, you could take advantage of some I/O operations and some zlib operations freeing the GIL for a bit. Unfortunately pip is the opposite use case, lots of tiny files.

> Interesting, I would be very surprised if this made a significant difference? but I'll take a look.

Optimizing empty files was actually quite worthwhile for pip, because about 10% of python packages are empty init files.

This might not give the same result for uv though. pip is fully linear, every single open/read/write/stat operation we removed was a direct performance gain. uv does parallel async IO, you could very well remove 10% of filesystem calls and barely affect the overall duration. :D

Also as a pip contributor. The only advantage of uv is to have support for parallel async extraction. If pip extracted multiple files/wheels in parallel without being blocked by the GIL, pip could easily match or outcompete uv.

I'm personally not looking forward to any deduplication/hardlink in pip. Hardlinks are very dangerous and system dependent.

It's very dangerous for empty files (init.py, empty.log yet not written). When the user edits one file, all files are modified simultaneously, all venv ever created by the user can be broken by editing one file, which is quite catastrophic.

It's also dangerous for small files with repeated content, for example random settings files that would contain a "1" or "true". Again, when the user edits one file, all files are edited and they were supposed to be different!

Hypothetically, a simple deduplication of binary files (.dll .so) should achieve 50% of the savings without significant drawbacks

I'd venture to say that pip extraction is more optimized than uv in at least one way. We have optimization for empty files (0 bytes) because there is nothing to write and checksum. uv doesn't seem to have the same optimizations, though I could be wrong, I just had a cursory look and my rust is not great. uv should probably review their treatment of empty files, it's counter productive to do any file system operation open/read/write because there is no content, it might be counterproductive to use any cache/comparison/hardlink if it takes more operations than doing nothing.

That's the one. Funny thing, it's not actually clickbait.

The bug made it to the kernel mailing list where some Intel people looked into it and confirmed there is a bug. There is a problem where is the kernel allocation logic was capped to 8 cores, which leaves a few percent of performance off the table as the number of cores increase and the allocation is less and less optimal.

It's classic tragedy of the commons. CPU have got so complicated, there may only be a handful of people in the world who could work and comprehend a bug like this.

If you're not aware, Intel has released a lineup of laptops, with some models having the GPU made by them and some having the same GPU made by TSMC. That makes the comparison very direct. TSMC can deliver nearly 3 times the power/performance.

GPU and CPU manufacturing is the same thing, same node, same result. GPU is always maximizing perf/power ratio because it's embarrassingly parallel, leaving no room to game the benchmark. CPU can be gamed by having a single fast core, that drops performance in half as soon as you use another core.

> I wonder whether the next bottleneck becomes software scheduling rather than silicon

Yep, the scheduling has been a problem for a while. There was an amazing article few years ago about how the Linux kernel was accidentally hardcoded to 8 cores, you can probably google and find it.

IMO the most interesting problem right now is the cache, you get a cache miss every time a task is moving core. Problem, with thousands of threads switching between hundreds of cores every few milliseconds, we're dangerously approaching the point where all the time is spent trashing and reloading the CPU cache.

> These sorts of core-density increases are how I win cloud debates in an org.

The core density is bullshit when each core is so slow that it can't do any meaningful work. The reality is that Intel is 3 times behind AMD/TSMC on performance vs power consumption ratio.

People would be better off having a look at the high frequency models (9xx5F models like the 9575F), that was the first generation of CPU server to reach ~5 GHz and sustain it on 32+ cores.

Not competitive at all. It's easily visible on the laptop lines, where the same GPU manufactured on TSMC has 3 times the power/performance ratio compared to the Intel one.

Putting more cores is just another desperate move to play the benchmark. Power is roughly quadratic with frequency, every time you fall behind competition, you can double the number of cores and reduce the frequency by 1.414 to compensate.

Repeat a few times and you get CPU with hundreds of cores, but each core is so slow it can hardly do any work.

Worthwhile to point out: The Cat5 cable required for gigabit Ethernet is merely twisted pairs with no insulation, which is pretty much a dumb basic cable (with 8 wires). That's why any cable can work in practice.

I don't know how possible it is to find a really bad cable (untwisted) and it might work on a short length anyway. (Your 1980s office cabling must have been 8 wires if you were able to get gigabit later, so it was far beyond basic phone wires or Cat1 from the time).

> Does anyone actually know why they don't offer a symmetric product like the niche fibre ISPs?

Short version: The UK regulator OFCOM defines ultrafast internet as 30 Mbps download speed. That's why UK internet providers (openreach and related) have deals starting as low as 30 Mbps and they can't be arsed to provide a faster speed (unless you pay £££).

> I believe that I have noticed that smaller games (~a few hundred MB or maybe a GB or two) will download quite a bit slower than large games, but I'm not very confident in that observation.

You can see that on the HellDivers screenshot, it takes 20 seconds to reach 500 Mbps, because TCP takes a while to adjust the bandwidth and is very conservative. TCP and home computers are not designed to make use of gigabit connections.

Old houses should have 1 extra socket in the master bedroom at the very least, because the master of the house was expected to plug a phone in there, back in the days. (my parents and grandparents all have one).

Incidentally, this is likely to be the furthest room on the furthest floor, so it can be a good place to add a wifi access point for coverage.

> the cables don't have a little chip or anything saying "I'm not suitable for high speed" the card will figure out whether this looks plausible and just do it.

You're actually wrong on all of that ^^

The cables actually have a rating to say what they are suitable to. See the markings on the cable: category Cat5/Cat5e/Cat6 + frequency range 100/250 Mhz + insulation UTP/FTP/STP/mix.

Ethernet cards don't negotiate, they typically only check whether the pairs can transmit any signal. You could end up in a situation where they go for gigabit and it doesn't work well.

Fortunately, the main issue for signal transmission is loss over distance. Ethernet is designed to work over 100m every time in a noisy industrial environment. You've got a pretty good chance for it to work on a short run, even with poor cables.

The alternatives being discussed ADSL/VDSL/G.hn actually detect the capability of the medium and adjust the transmission rates and frequency to give the maximum possible speed. IMO they are much more advanced technologically and much more interesting. (Ethernet is doing exactly 250 Mbps on one pair, G.hn can do up to 1700 Mbps on the same pair, automatically adjusted, the article is getting 1300 Mbps which is insane!)

It's a setup seen in a lot of new builds flat from the 2000s and 2010s, which is a very large amount of the housing stock in London for flats (There has been so many constructions!).