There are also mode switching and calling convention issues.
The way that the vector registers were extended to 256-bit causes problems when legacy 128-bit and 256-bit ops are mixed. Doing so puts the CPU into a mode where all legacy 128-bit ops are forced to blend the high half, which can reduce throughput of existing SSE2-based library routines to as low as 1/4 throughput. For this reason, AVX code has to aggressively use the VZEROUPPER instruction to ensure that the CPU is not left in AVX 256-bit vector mode before possibly returning to any library or external code that uses SSE2. VZEROUPPER sets a flag to zero the high half of all 256-bit registers, so it's cheap on modern x86 CPUs but can be expensive to emulate without hardware support.
The other problem is that only the low 128 bits of vector registers are preserved across function calls due to the Windows x64 calling convention and the VZEROUPPER issue. This means that practically any call to external code forces the compiler to spill all AVX vectors to memory. Ideally 256-bit vector usage is concentrated in leaf routines so this isn't an issue, but where used in non-leaf routines, it can result in a lot of memory traffic.
Don't think the memory operand version would work here. If I understand the x86 architectural manual description, the 32-bit operand form interprets the bit offset as signed. A 64-bit operand could work around that but then run into issues with over-read due to fetching 64 bits of data.
The VS debugger got an order of magnitude slower in the transition from VS6 to Visual Studio .NET. It's been sped up a bit but is still nowhere near as fast as the VS6 debugger at responding to step commands, debug output, or conditional breakpoints. In VS.NET you could be waiting as long as a full second on a contemporary dev machine for the debugger to finish stepping forward one line.
Funny thing is that at the time, I was lamenting how much slower VC6 was than VC4. Macro playback, for instance, got much slower in VC6. It's all relative.
Yeah, unfortunately this seems to combine the UI and performance issues of LibreOffice with new issues from the new front end.
It also has a basic mistake in text editor UX: the caret blinks independently of caret movement. This means that the caret is invisible half of the time while trying to navigate text. Most text editors avoid this by restarting the blink cycle to force the caret visible on each movement.
> It also has a basic mistake in text editor UX: the caret blinks independently of caret movement. This means that the caret is invisible half of the time while trying to navigate text. Most text editors avoid this by restarting the blink cycle to force the caret visible on each movement.
It doesn't do that on my computer. LibreOffice 7.0.4.2 shipped with GNU/Linux Debian.
A major culprit is background processes that scan the drive in the background, like CompatTelRunner.exe. Works fine if you're on an SSD, but grinds an HDD to a halt. They also forgot about their own I/O prioritization API from Vista, so it also spammed I/O at Normal instead of Background priority in the early versions. Not to mention the periodic Defender scans, the Malware Removal Tool scan that runs before each major update, etc.
Similarly, Windows Update used to consume ungodly amounts of CPU time because the update system would write a multi-hundred megabyte text log and then spend forever compressing it for upload. Then they remembered their own ETL system and switched to much more efficient binary logs.
Firefox also has problems on HDD, I remember it locking up for minutes at a time doing cache maintenance until I switched permanently to SSDs.
The timeline for fast multiplies is also a bit off, IMUL was already 4c latency / 1c throughput on the Pentium Pro (1995) and Pentium II (1997). Pretty sure IMUL was also only a few cycles on the AMD K6 (1997). Though Intel slowed it back down again in the Pentium 4, until they reverted back to the P6 architecture in the Pentium M.
Typically intersection checks outnumber updates, so it's better to optimize the former. Also, that only works if the object's pivot is at the center of the bounding box or you're accumulating movements without an explicit position.
That being said, a lot of tricks work better with center/extent instead of min/max, such as computing the AABB around an OBB or doing separating axis tests with abs() tricks. A bounding box and bounding sphere can also be stored together as center/extent/radius with only one additional value needed. Min/max works better for accumulation, though.
This shows up in a lot of other areas, like small game companies that have a devoted following. It can get pretty nasty because these types of people are able to be condescending just short of ToS, while baiting other people into crossing the line. A common thread is weak moderation or biased moderation.
As a developer, it's easy to be blind to this because they're on "your side", but it's bad for the health of your support forums.
Wine has some gaping holes in some of its API implementations. Direct2D, for instance, has existed since Windows 7 but is badly implemented in Wine -- there is no antialiasing and the ArcTo() function draws a line. The MS documentation is not that great either, so fixing Wine isn't necessarily easier than porting to native.
The antivirus / EDR / monitoring / inventory software that most corporate IT departments installs ages computers ten years. We constantly had problems with such services slamming the disk, holding files open, breaking software, running CPUs at 100%, etc.
Crowdstrike Falcon is likely the only reason my work M1 Pro machine runs like a dog. Any time it's being a laggy piece of junk you can open Activity Monitor and see Falcon just slamming it.
Not my problem. You wouldn't need an antivirus with a properly locked browser with UBlock Origin and OFC no damn HTML email. GPO's blocking anything not being under an executable whitelist.
If any, your email client should open any attachment under a sandbox, such as Sandboxie, under a libre license:
The way that the vector registers were extended to 256-bit causes problems when legacy 128-bit and 256-bit ops are mixed. Doing so puts the CPU into a mode where all legacy 128-bit ops are forced to blend the high half, which can reduce throughput of existing SSE2-based library routines to as low as 1/4 throughput. For this reason, AVX code has to aggressively use the VZEROUPPER instruction to ensure that the CPU is not left in AVX 256-bit vector mode before possibly returning to any library or external code that uses SSE2. VZEROUPPER sets a flag to zero the high half of all 256-bit registers, so it's cheap on modern x86 CPUs but can be expensive to emulate without hardware support.
The other problem is that only the low 128 bits of vector registers are preserved across function calls due to the Windows x64 calling convention and the VZEROUPPER issue. This means that practically any call to external code forces the compiler to spill all AVX vectors to memory. Ideally 256-bit vector usage is concentrated in leaf routines so this isn't an issue, but where used in non-leaf routines, it can result in a lot of memory traffic.