6 ms·
You know what would be even better? Device drivers in a memory managed language like C#!
by fortran77 3y ago
You know what would be even better? Device drivers in a memory managed language like C#!
- j16sdiz 3y agoMany common device class supports user mode driver. I think that supports writing in memory managed languages
- AlectronikLabs 3y agoYeah, this is one of the reasons why I think a microkernel would be excellent for today's computing.
- danparsonson 3y agoWould that be better though? I have no experience of driver development by my feeling is that device drivers being low-level and fundamental building blocks of a working operating system, doesn't fit well with garbage collection interrupting execution on its own schedule.
- sonthonax 3y agoDepends what you’re writing to be honest.
- ndiddy 3y agoI’d prefer not to have my mouse stutter because the driver paused to run the garbage collector.
- londons_explore 3y agoDays of lag-free mice are well and truly over... (Sitting here running wayland, where the mouse feels stuck in molasses!)
- morjom 3y ago(Sitting here running Wayland aswell, where the mouse feels just fine)
- self_awareness 3y agoI wish I had a problem with mouse on Wayland, but it doesn't run for me at all
- tentacleuno 3y ago(Sat here using KDE Plasma on Wayland where the mouse lagged and glitched every time you opened a program.) I think later versions fixed this one, though.
- viraptor 3y agoThat's not a Wayland issue. It may be a specific Wayland bug that affects you, but the architecture of the system does not force any extra delays.
- londons_explore 3y agoImagine we are half way through sending a frame to the display. The cursor is in the bottom half of the screen. If I move the cursor, that should be represented in the frame that's being currently outputted, not the next frame. Wayland has no support for that, by design. The end result is that there is always a delay of at least one Frame.
- vlovich123 3y agoThere are ways to solve that and it’s not an architectural flaw. You just need prediction in the compositor to adjust the location of the mouse. But honestly, the difference of a frame of latency is ridiculously difficult to feel and we’re talking about a half frame of latency here on average. It’s almost likely something else considering the entire end to end latency here is closer to 50-100ms on most systems and still isn’t what people would describe as laggy. Usually it’s some kind of software bug/hiccup that interrupts things to not be rendered at a constant tick rate or just getting hung and not processing events in a timely fashion.
- jayd16 3y agoIt's not that hard to write no-alloc C# code. Happens in Unity dev all the time.
- chrisandchris 3y agoIt's not, no. But it's also very easy to write alloc C# code and people will if you give them the option. That won't be possible in Rust / C.
- charcircuit 3y agoEven so 16.666 ms is a lot of time for just handling mouse input.
- satvikpendem 3y agoAttitudes like these is how we eventually end up with bloated messes like Electron. Performance matters, everywhere. Some of us increasingly also use monitors with more than 60 hertz.
- mkl 3y agoThe CPU has other things to do too.
- charcircuit 3y agoNo matter what you do the CPU will always have other stuff to do.
- IshKebab 3y agoSo you agree...
- RetroTechie 3y agoYes. 640 usec should be enough for every mouse.
- 3y ago
- Ciantic 3y agoMouse stutter has become more common in Windows. Every time I open a web page with Spotify embed mouse freezes for ~0.5 to 1 second and then continues moving, I haven't found any reason for it, it happens with Firefox, Google Chrome, and Edge. It's been repeatable ever since I bought a Ryzen 7950X at the beginning of the year, that's why I tried using system profiler tools to find the reason but as I have no good experience in this it's difficult to find the root cause.
- sorenjan 3y agoI had similar problems maybe 15 years ago, so I don't remember exactly how I solved it. In my case it was a NIC driver that filled up some queue when I downloaded "Linux ISOs" too fast over bittorrent. There are tools available to find the source of the problems, I think I used event tracing as a starting point. https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/event-tracing-for-windows--etw- https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
- hobs 3y agoUnplug and try a different mouse. Unplug and disconnect any other peripherals except the mouse and try that. Try a new user on windows (user space apps) Try a fresh install (system stuff) If you have spinning rust try another hard drive (an app doing stupid blocking exclusive stuff with writing or reading can pause input stuff).
- seritools 3y agoDid you do any overclocking (especially RAM)? I've seen issues like this with either slightly unstable OC, or bad drivers. I'd also suggest running https://www.resplendence.com/latencymon https://www.resplendence.com/latencymon to see if it's a specific driver causing the stalls, or if it's random.
- chiph 3y agoI noticed it after I upgraded to a 3900X. Not sure if it's an AMD thing, a USB hub thing, or a many-core thing. But it had never happened before. (Microsoft Pro Intellimouse)
- mhh__ 3y agoAs opposed to a stall induced by reference counting? Don't allocate => don't need to collect.
- dataking 3y agoI'm not aware that C# has security or reliability advantages over Rust. It may be better integrated into the Microsoft ecosystem but from the point of view of a driver developer who has to support more than one OS, Rust would seem to be a good tradeoff between security, performance, and reliability vs. C/C++.
- Yoric 3y agoI'm a big fan of Rust (and a minor contributor), but one can't deny that a garbage-collector makes most developments much easier. Now, I'm not convinced that a gc makes much sense in driver development, but I could be wrong.
- deleted 3y ago[deleted]
- dboreham 3y agoNot wrong. Kernels usually have their own memory management schemes, tied to the lifetime of i/o ops and so on. It would make more sense to somehow integrate that into the driver programing language.
- knorker 3y agoIt makes some things easier, and some things harder, or more complex. So I can deny that most development becomes easier with GC. At least if you also intend to actually run the thing. Running Java means forever fighting the GC, needing to do runtime and development to reduce impact of inherent GC problems.
- shanoaice 3y agoBut it's a Java issue: Java relies on Heap Objects way too much. C# and the CLR behind it has a much better support for value types and stack allocations, where some optimization can even be done by the JIT compiler.
- 3y ago
- __jem 3y agoRust is memory managed, it just doesn't have a garbage collector.
- jenadine 3y agoIt's a static garbage collector
- BadBadJellyBean 3y agoOr a garbage denier
- anon25783 3y agoHow would this work? And why would it be a better idea?
- mustache_kimono 3y ago> How would this work? Don't know exactly what you're asking. > And why would it be a better idea? Poorly written device drivers are a significant attack vector. It's one of the reasons Linux is now exploring using Rust for its own device drivers.[0] You may be asking -- why Rust and not some other language? Rust has many of the performance and interoperability advantages of C and C++, but as noted, makes certain classes of memory safety issues impossible. Rust also has significant mindshare among systems programming communities. [0]: https://rust-for-linux.com https://rust-for-linux.com
- anon25783 3y agoYeah okay but device drivers in C#? That sounds very impractical when you could pick any other language. C, C++, Rust, D, Zig, Objective-C, all seem more suitable than C#. I agree with all that stuff you said about Rust; I was asking how drivers in C# would work
- pjmlp 3y agoLike this, for a possible example, https://github.com/WildernessLabs/Meadow.Foundation https://github.com/WildernessLabs/Meadow.Foundation
- raincole 3y agoC# is my main language but this is one of the few cases where it's not the best choices.
- MStrehovsky 3y agoHere's an example [1] of a device driver in C#. It is possible. It is also not recommended. [1] https://github.com/VollRagm/KernelSharp https://github.com/VollRagm/KernelSharp
- sebazzz 3y agoI thinking “this is some project probably written years ago and loading the .NET Framework runtime into kernel space” but this is actually using NativeAOT and the latest features/SDK.
- nextaccountic 3y agoC# doesn't help against data races Indeed pretty much no mainstream language prevents data races at compile time like Rust does
- deleted 3y ago[deleted]
- pjmlp 3y agoRust only helps in a specifc use case of data races, when the memory belongs to the same process and is being access by threads. Rust type system doesn't help when the data resides in a shared memory segment accessed by multiple processes.
- nextaccountic 3y agoRust helps against data races in a kernel, as shown by the Rust for Linux project and other kernel projects (Redox, etc). Of course if you interact with foreign code (including code in other programs, but also code in the same program written in another language), you need unsafe. Or if you write a new synchronization primitive, etc. The unsafe is there to say "I manually checked and this is okay". What's important is that with Rust, concurrent business logic - in a kernel, things like filesystems and drivers - shouldn't need any unsafe to synchronize correctly. You use unsafe for your lower level infrastructure, but the code that actually does things can be data race free (and thus is easier to modify and assure it's working correctly). And that's incredible.
- pjmlp 3y agoFilesystems get modified by third parties. Also the right way to implement filesystems and drivers in modern OSes should be in userspace drivers, which is the route being taken by Apple, Google and Microsoft across their OSes anyway.
- deleted 3y ago[deleted]
- anaisbetts 3y agoIt is very difficult to write device drivers in even C++ while still maintaining the ability to write pageable kernel drivers. Drivers must have very strict control over availability of memory because it will likely access it at times when a page fault is not possible (i.e. during an interrupt handler). The C# language and runtime would have to add features to explicitly accomodate this at a bare minimum
- tonyedgecombe 3y agoMicrosoft did have an experimental OS[1] written in a variant of C# so it doesn't seem completely unrealistic. [1] https://en.wikipedia.org/wiki/Midori_(operating_system) https://en.wikipedia.org/wiki/Midori_(operating_system) My guess is the internal politics would be a bigger problem than any technical issues.
- anaisbetts 3y agoIt's not unrealistic but Midori made a lot of changes to C# to make it possible, it was almost a different language by the end of the project
- CodeCompost 3y agoMicrosoft tried that already. It failed miserably. I don't think they gave a reason but I suspect that garbage collection caused too many freezes in early 2000s hardware.
- resonious 3y agoMaybe I'm wrong but I suspect your parent comment was alluding to that sarcastically.
- pjmlp 3y agoIt didn't fail, it was sabotaged by Synosfky and friends, which then carried on doing exactly the same ideas with COM and C++. Guess why UWP applications are much slower than regular Win32, app sandboxing and COM reference counting. But hey, they won.
- iknowstuff 3y agomacOS sandboxes apps, which are usually written in Swift or ObjC and thus use reference counting, and doesn’t suffer from the kind of slowness that plagues UWP. So your hypothesis appears to be incorrect
- SSLy 3y ago> it was sabotaged by Synosfky and friends Is this described anywhere in detail?
- pjmlp 3y agoYes, basically when Longhorn started to fail to meet expectations, there were two possible ways, do what Google did with Android, push forward no matter what to make it work, or forcing a rewrite into something else, which is what WinDev ended up doing. "What Really Happened with Vista" https://hackernoon.com/what-really-happened-with-vista-4ca7ffb5a1a https://hackernoon.com/what-really-happened-with-vista-4ca7f... "Turning to the past to power Windows’ future: An in-depth look at WinRT" https://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/ https://arstechnica.com/features/2012/10/windows-8-and-winrt...
- ww520 3y agoLook into the Singularity project.
- jeroenhd 3y agoMicrosoft is pushing more and more code into user space. The latest change is that they now insist printer manufacturers use UWP printer apps rather than drivers to add custom functionality to their printers; these apps are usually written in languages like C#. I agree with Microsoft that the best method is probably to run less manufacturer code in the kernel, not to make the kernel accessible more easily. Running a garbage collector in the kernel sounds near impossible to pull off without GC bugs because C# isn't exactly suited for "I want to access some buffer but I can't because it hasn't been paged in and I'm in an interrupt handler".
- pjmlp 3y ago> The latest change is that they now insist printer manufacturers use UWP printer apps rather than drivers to add custom functionality to their printers; these apps are usually written in languages like C# it would be nice, however .NET Native is deprecated, Native AOT doesn't do UWP, and WinDev is pretty bullish in C++.
- GoblinSlayer 3y ago>Native AOT doesn't do UWP Is there a need for it? Printing isn't performance sensitive.
- pjmlp 3y agoThe UWP execution model to start with, no JIT code allowed, based on COM.
- GoblinSlayer 3y agoAIU the package for Windows Store contains msil, then Windows Store figures out what to do with it.
- pjmlp 3y agoDepends, it can be already compiled to native code, in the case of still having MSIL, it is compiled by Windows Store before becoming available for distribution. From the point of view of consumer, it is all AOT compiled code.
- fortran77 3y ago[flagged]