Microsoft allows you create a second "login only" account username to access your e-mail and other services. I was having the same problem as you but much worse. Check into it, only takes a few minutes to setup.
It must be hard to be in a position to be blamed for someone else's bad code - or even malware - one comment said it was 1/3 of the total crashes on Vista at the time.
As a GPU driver dev I 100% understand this position - no user cares that gamedevs are hacking things left and right, they care if it runs.
There's plenty of blame to go around, really. My current project has a workaround for a user-mode graphics driver that sets the thread name without checking if D3D11_CREATE_DEVICE_SINGLETHREADED is set -- so there's code to detect this and call SetThreadDescription() to change it back so the main thread can be found in the debugger again.
There also used to be a problem with a release DLL in Windows 10 that would output to OutputDebugString() with an encoding mismatch, thus spamming the debug output window with random kanji.
I've heard that the Office team has resorted to detouring SetUnhandledExceptionFilter() since even they had problems with third party DLLs unhooking their in-process crash handler.
> There's plenty of blame to go around, really. My current project has a workaround for a user-mode graphics driver that sets the thread name without checking if D3D11_CREATE_DEVICE_SINGLETHREADED is set -- so there's code to detect this and call SetThreadDescription() to change it back so the main thread can be found in the debugger again.
I hope that wasn't the one I worked on :P Though I'm surprised that changed much there - the flag just means we can avoid wrapping some state in mutexes (and in many paths is a NOP as the driver still uses multiple threads internally, not worth the gain for the few things they won't touch), I'm surprised that makes it rename the user thread.
From what I can tell, the driver author simply assumed that the user-mode graphics driver was running on a dedicated worker thread, and unconditionally set the thread name. However, when single-threaded mode is in use, it gets invoked on the application's thread -- and thus changes the name of the main thread instead.
CEF had this issue as well, and the result was that initializing the WebBrowser plugin in Unreal would rename the main thread there too.
That's why I'm surprised - that flag doesn't mean we don't spawn worker threads for the driver, just that user API calls only come from a single thread.
I suspect this is someone assuming the flag actually mean "the driver should only use one thread" - or more likely a popular app assumed that and relied on that behavior, and the driver ended up having to emulate that behavior and you app just happened to hit whatever heuristics enabled that option.
It feels like half the driver size is due to nonsense "workarounds" like that - like the recent Fallout3/New Vegas issue was due to the app trying to autodetect the driver and versions and doing something slightly different (which hasn't really been "valid" since soon after release) - so when a version number or driver ID changes a little too much for it to cope with it completely fails - so we added an entire new "fake" driver that just lies about it's name and version.
It's honestly a PITA and something I've hit on different vendor's driver in my own projects - you can rename the executable and get completely different behavior.
It's probably not surprising that GPU drivers are hundreds of megabytes in size, even compressed :P
The thread description is only for debugging purposes, though, and is only available on newer versions of Windows 10 anyway. I'm more inclined to believe it's an oversight as games seldom request non-thread-safe operation.
As for detecting the driver, yeah, it's easy to get that wrong. IIRC, GL drivers on Windows had to limit their reported extensions because GLQuake would overflow a buffer if the extension string was too long. I also saw a game where the telemetry code had a bug and would crash if the driver description was too long. Then there was the extreme weirdness with early hybrid devices where you'd bring up DXDiag and it'd say that the system had an Intel Integrated Graphics adapter driven by an ATI graphics driver DLL!
The root of all of this is that modern GPUs/drivers/graphics APIs are hugely complex. These days, drivers have entire compilers built into them, that are expected to run as fast as possible under demanding conditions while generating efficient shaders. But again, anyone who thinks the fault mainly is on one side is getting an incomplete picture. I remember the DirectX team complaining about how in the early days of Vista about how a large %age of their driver crashes were from NVIDIA drivers. On the other hand, NVIDIA said that they had to redesign and rewrite six full drivers from scratch on top of a new architecture with incomplete documentation that was changing up to the last minute.
It's a very common security technique to avoid being targeted by malware. I believe even the Microsoft KSLDriver drops randomly named DLL and device drivers along with creating a randomly named system service. Uses 8 hex characters.
Several third-party vendors use the same technique, mostly security vendors.
I'm the engineer who spearheaded adding the blocking technique outlined by OP. Security vendors are some of the worst offenders when it comes to injecting buggy DLLs into processes.
Looks like Moonshine is competing against the Whisper-tiny model. There isn't any information in the paper to see how it compares to the larger whisper-large-v3.
I'm not an AI person, in any technical sense. The savings being claimed, and I assume verified, are on ARM and x86 chips. The piece doesn't mention swapping mult to add, and a 1-bit LLM is, well, a 1-bit LLM.
Also,
> Additionally, it reduces energy consumption by 55.4% to 70.0%
With humility, I don't know what that means. It seems like some dubious math with percentages.
Not every instruction on a CPU or GPU uses the same amount of power. So if you could rewrite your algorithm to use more power efficient instructions (even if you technically use more of them), you can save overall power draw.
That said, time to market has been more important than any cares of efficiency for some time. Now and in the future, there is more of a focus on it as the expenses in equipment and power have really grown.
Run the non-quantized version of the model on your 3090/4090 gpu and observe the power draw. Then load the 1.58 model and observe the power usage. Sure, the numbers have a wide range because there are many gpu/npu to make the comparison.
Yeah, I get what you're saying but both are challenging the current MatMul methods. The L-Mul paper claims "a power savings of 95%" and that is the thread topic. Bitnet proves that at least 70% is possible by getting rid of MatMul.
No, if I remember correctly it was a local beverage company. It wasn't unusual for Microsoft to back local businesses. I remember a very talented Indian software engineer that left Microsoft and purchased 3 "food trucks" and decided to serve food instead, true story. He parked his truck outside building 88 for a few years.
What Windows 7 telemetry are you referring to? Other than WER, there was no telemetry in Windows 7 to my knowledge. There was an update a few years ago that back ported telemetry to Windows 7 right before the final stage of extended support and final EOL.
Back when Microsoft started pushing telemetry in Windows 10, they added additional telemetry to Windows 7 through updates. Not nearly as pervasive and omnipresent as with Windows 11, though; you can just remove the telemetry updates: https://gist.github.com/xvitaly/eafa75ed2cb79b3bd4e9
Yes, it was me that backported some of that telemetry to both Windows 8.1 and Windows 7, circa 2015 when I was working on the WU team but we used WER to upload that to our endpoints. I don't think there was any telemetry at all before 2015 in the base operating system.
