[HN Gopher] 24-core CPU and I can't move my mouse (2017)
___________________________________________________________________
24-core CPU and I can't move my mouse (2017)
Author : thunderbong
Score : 147 points
Date : 2022-12-22 16:23 UTC (6 hours ago)
(HTM) web link (randomascii.wordpress.com)
(TXT) w3m dump (randomascii.wordpress.com)
| datavirtue wrote:
| Windows?
| salawat wrote:
| If I recall, this is mainly caused by the shift to USB as the
| connector du jour. Since it's a poll centric protocol, under
| heavy load, system responsiveness decays.
|
| Back in the days of P/S 2, where input was interrupt driven, the
| background tasks would be interrupted by input coming in,
| ensuring the user could move the mouse around. Now whether they
| could get the outcome of a click to register is a different
| story. The click would, but there'd be no guarantee the click
| handler would execute before background processing resumed,
| because it'd be considered an event that'd get scheduled after
| whatever is currently starving the CPU thread.
| spogbiper wrote:
| As I understand it, the polling is done by the USB controller,
| not the operating system or anything happening in the system's
| CPU.
| the__alchemist wrote:
| On the MCU (device) side, you can command the poll in a data-
| received interrupt. Does it not work that way on the PC side?
| Ie, you never have to really block on the MCU.
| dezgeg wrote:
| Sure, on the wire USB is a polling protocol. But the polling is
| done by the host controller hardware, which will raise an
| interrupt just like PS/2 whenever the device responds to the
| polling as having data available.
| neonbeige wrote:
| The polling by the host controller is still limited to
| happening once every bInterval period as specified by the
| device, which for mouse/keyboard will be at least a few
| milliseconds, v.s. the old school PS2 style mice which would
| send hardware interrupts straight to the processor.
| dezgeg wrote:
| Yes, but that sort of 'delay' will be there all the time,
| with no relation to the system being loaded (like the top
| commenter is claiming).
| taeric wrote:
| The article is about a bug in process destruction, if I'm not
| mistaken. The mouse bit is a bit of an aside. More of an
| obvious symptom that something is wrong.
|
| Not that interrupt based input processing didn't have some
| advantages. Just this shouldn't be one of them.
| WalterBright wrote:
| I use Thunderbird for my email. Its behavior shows it is a
| multithreaded program.
|
| But often, the mouse and keyboard will freeze and it becomes
| unresponsive for several seconds. This is indicative of
| suboptimal partitioning of the tasks into threads. The highest
| priority thread should be responding to user input.
|
| Heck, back in the 1970s, I designed and built a single board
| computer that was to be a glass tty. There was no way to get that
| 6800 uP to update the screen fast enough to keep up with
| characters arriving at 9600 baud.
|
| The solution was, whenever the user hit a key, to abandon
| updating the screen and process the character. Once that process
| was complete, and there were no more keys in the input, the
| screen updating was restarted.
|
| It worked out great. You simply never noticed this was happening,
| and you always got crisp response.
|
| I did the same thing for the MicroEmacs text editor on the IBM
| PC. If I hadn't, the editor would lose input and/or have
| noticeable lags refreshing the screen.
|
| P.S. The importance of not losing input was necessitated by using
| ttys to transfer files across the phone lines and serial ports.
| You also couldn't touch type if the tty lost key input.
|
| P.P.S. The Chrome browser that I use also has problems with
| freezing on keyboard input.
| nix23 wrote:
| I can crash Linux(all tested distros >5 for at leat 3 years)
| and FreeBSD reliable with Thunderbird, it's a terrible
| application and a statement for GUI-oss-applications....pure
| shame....
|
| Edit: and no, not with root or a "wheel"-User
| spacechild1 wrote:
| For me the UI hangs whenever Thunderbird downloads new
| messages. It seems as if they are doing network I/O on the UI
| thread - which can't be true...
| WalterBright wrote:
| I learned not to touch the keyboard when TB was downloading
| new messages and running filters. Otherwise it would randomly
| corrupt the message file, and I'd lose it all. Yes, I filed a
| bug report with TB. No, they never found the problem.
| jiggawatts wrote:
| I stopped using Thunderbird a long time ago because it had
| a "feature" that would erase all of your email if it
| detected that your profile was corrupt...
|
| ... but it has a habit of corrupting profile files on
| shutdown.
| dekhn wrote:
| even by mid-80s, if you used the naive serial routines built
| into the Apple IIe you couldn't do 1200bps- 300bps worked.
| Professional terminal programs used interrupt and buffers to
| capture incoming bytes while the screen scrolled (https://sites
| .google.com/site/drjohnbmatthews/apple2/ssc?pli...). At least
| that's what the author of ProTERM told me when I was a kid and
| I asked how it worked. It sounded pretty exotic at the time but
| now I work with low-level hardware... $5 chip that can do 2Mbps
| over serial.
| WalterBright wrote:
| Yup, ISRs are the solution for 6800 and 6502 chips.
|
| Data I/O's LogicPak (powered by a 6502) used polling, and
| would now and then lose data because of that. I advised the
| engineer working on it to just write an ISR. Months went by,
| while he was convinced he could make the polling work.
|
| Finally, the manager dropped by and asked if I could just fix
| it. In a couple hours had it fixed with an ISR. No more
| problems.
| andrewstuart wrote:
| This is one of the primary resaons I ditched Windows for Macos.
|
| The multitasking on Windows is ridiculously bad.
|
| Also, applications that freeze and can't be killed/restarted are
| simply part of life on Windows.
|
| Add to all that, Window slows down over time - again, the
| periodic reformat and rebuild is part of life on Windows. After I
| switched to Mac I didn't need to rebuild the operating system
| essentially ever.
|
| Also, the registry - I think the worst idea in all computing.
| Prior to the registry you plopped a windows application in a
| location and configured it with an INI file. After the registry
| the entire operating system and all applications turned into one
| big ball of chewing gum, glue and hair dredged out of the shower
| drain.
|
| How can Windows have got it so wrong?
| jorvi wrote:
| I wrote a long comment on my phone telling you how this is
| simply untrue.
|
| During the typing of the comment, Safari locked up and then
| hard-crashed, losing my comment.
|
| If that happens on something as tightly-controlled as iOS, how
| many bugs and crashes do you think macOS and it's apps
| experience?
|
| The main difference between macOS and Windows or Linux, I'd
| say, is that bugs on macOS are more submarine. Windows also has
| much stronger recovery mechanisms, to the point where a GPU
| crash barely phases it. A GPU crash on macOS will hard-reboot
| the system and possibly show you a ':-)'.
| Dah00n wrote:
| I have been where you are, posting the same thing, but I don't
| believe it is true today. Applications that hang and can't be
| killed is a much bigger problem to me in Linux than in Windows
| 10. I also don't reformat, at most i reset Windows or
| applications but it has been years. I agree with the rest but
| in everyday use the registry is not a problem in Windows.
|
| The difference to me is that I as a power user might be able to
| fix it myself in Linux but by only using the tools normal users
| know of I must say I cannot recognize that this is a weak point
| in Windows today. Clicking the X to close an app and getting
| stuck with a dead app is much worse in, say, Debian than in
| Windows.
|
| With that said.. I don't use Windows where I have a choice but
| that is mainly for philosophical reasons these days. Mac I
| don't touch. I feel it is the worst of both camps.
| AnimalMuppet wrote:
| > Applications that hang and can't be killed is a much bigger
| problem to me in Linux than in Windows 10.
|
| Have you seen anything in Linux that you can't kill with
| "kill -9"?
| wazoox wrote:
| I have a nice shortcut : Windows+K calls "xkill" :)
| ufmace wrote:
| Anecdotally, that's not my experience with Windows these days
| at all. I've never had the whole system freeze up on my Win10
| desktop. Never noticed a slowdown or app that can't be killed,
| and never done a reformat or rebuild. Windows Update is mildly
| annoying when it decides to reboot your system for you, though
| usually when you're not using it. The registry seems fine to me
| too. Okay it's not perfect, but I don't think it's meaningfully
| worse than the MacOS or Linux system of configs in text files
| with various types of special formats all over the place,
| unless of course it's some kind of binary format that can only
| be modified with a special CLI program.
| IshKebab wrote:
| I agree. Windows is basically fine these days. It's even
| better than Mac and Linux in a big way from a desktop
| stability point of view because it has the Ctrl-alt-delete
| interface which works reliably and lets you kill the
| offending program.
|
| Linux has various useless options like sysreq shortcuts that
| you can't remember and kill random processes, and I don't
| think Mac has anything, though to be honest I don't recall
| ever bringing a Mac to its knees so much that I couldn't open
| a terminal and run `top`.
| int_19h wrote:
| I wish Ctrl+Alt+Delete would be reliable enough to work
| with full-screen games. But, half the time, when you try to
| launch Task Manager that way to kill the offending process,
| it ends up under the game's output. I've learned to kill
| processes using keyboard navigation by looking at Task
| Manager's thumbnail in Alt-Tab process list, but it's
| ridiculous that we still need to do this kind of dance in
| 2023.
| faebi wrote:
| My windows literally doesn't boot today due to a bluescreen.
| No idea why or how that happened. Had it a few times in life
| before, but never on macos.
| seanw444 wrote:
| _ahem ahem_ gconf _ahem ahem_
| nailer wrote:
| I think all desktop OSs have it wrong. Allowing full APIs to
| backgrounded apps and no CPU reservation for control apps will
| ultimately end desktop computing - we'll create on iPads
| because they work.
| rbanffy wrote:
| I'm writing this on an old i3 and it feels perfectly fine. It
| would probably take days to compile a large project like
| Chrome or LibreOffice, but, as long as I run the make under a
| nice, I can continue using the computer and the only sign
| something big is happening will be the CPU fan kicking in.
| w1nst0nsm1th wrote:
| > This is one of the primary resaons I ditched Windows for
| Macos.
|
| The raison I just ditched Fedora for ubuntu...
|
| The raison I ditched MacOS for Windows is that MacOS is slowly
| but surely becoming a magnified version of iOS... One day you
| will have to jailbreak if you want administrator rights on your
| ~~personal computer~~ Macbook.
| kevmo314 wrote:
| Did they? My MacBook is much worse at multitasking. In fact the
| OS I've found to be best at multitasking is Debian/Ubuntu.
| fmajid wrote:
| The GUI is still essentially single-threaded. Only BeOS with
| its fully parallel UI had it right.
| rbanffy wrote:
| IRIX remained quite responsive no matter how much I threw
| at it.
| yamtaddle wrote:
| Switching from FF to Chrome (this was like a decade ago, to
| be fair to FF) eliminated about 50% of my beachballs and
| other unresponsiveness system-wide, not just when using FF.
| Switching from Chrome to Safari got rid of almost all the
| rest, and also made my battery life match Apple's claims.
|
| [EDIT] And when I _do_ still run into trouble, it 's almost
| always Electron chat apps. Slack, Teams, and Discord. All
| terrible at being respectful of system resources. Closing the
| program and restarting it usually temporarily fixes the
| problem, but that shouldn't be necessary.
| PuffinBlue wrote:
| A very unreasonable reason for me not switching to Safari
| is because the bookmarks dropdowns (when activating the
| bookmark bar) have two very annoying features. Firstly they
| only open when clicked, so if you click one and move your
| mouse to another, the other doesn't open, just the original
| stays there and you have to click off it to close it.
| Secondly there's some kind of delay to that click such that
| if you accidentally click the wrong folder of bookmarks,
| click off it to the correct folder and click again to open
| the correct folder, if you click too fast it'll do nothing
| - no opening the new folder, nothing. And it'll continue to
| do nothing if you continue to click 'inside' the timeout
| window. So you have this artifical delay built into
| bookmark navigation that just put me off.
|
| That and also ultra-wide tabs which change in size as you
| close them with a middle click, which is really annoying
| and you sometimes close the wrong tab. Close them with the
| cross and they stay the same size and neatly collapse, you
| can even then middle click to close the remainder and they
| stay the same size. Silly difference in behaviour IMO.
|
| It's the little things that put me off. Shame, as Passkey
| support is great.
| rbanffy wrote:
| My own personal experience (recent x86 based MBPs and
| similar) is that macOS degrades quickly when CPU and IO get
| stressed, but Windows 10 and 11 become unresponsive with much
| smaller loads. Of the big three, Linux is the one that can
| take more processes while still being responsive.
|
| Even a lowly old i3 can encode videos with ffmpeg while you
| browse the web provided you start ffmpeg with a `nice -n 19`.
| On a Mac, it seems to be ignored.
| jorvi wrote:
| Linux UI actually becomes very unresponsive under load (on
| most distros) because the default kernel scheduler is tuned
| for throughput at the cost of responsiveness, instead of
| vice versa.
|
| Desktop distros switching to a more user-friendly
| scheduler, and loading a 'small speaker' EQ via Pulse on
| detecting internal speakers (= laptop) are two massive,
| low-hanging fruit improvements for Linux that just don't
| seem to be done.
| andrewstuart wrote:
| Can I ask what model and how much RAM?
| kevmo314 wrote:
| 2019 13" MBP, 16GB. Pretty much anything I do will spin up
| the fan now. Compiling an app uses so much battery that I
| get less than an hour of battery life. I've resorted to
| remote development only, a la Chromebook.
|
| My previous laptop was a similar Lenovo X1 Carbon with
| Debian and wow do I miss it, but I don't have too much of a
| choice since I do mobile app development :(
| ab-dm wrote:
| Yeah, the 2019 MBPs were absolute abominations. I spent
| 5k AUD on a fully kitted out MBP and performance wise
| it's one of the worst computers I've ever owned.
|
| I swore that would be the last Apple computer I ever
| bought, but then they released the M1s... and they are
| very good.
|
| Would recommend getting an M1 if at all possible. There's
| still time to ask Santa for one.
| stavros wrote:
| I recommend getting a Framework. It's probably not as
| good as an M1, but it'll last you more than two years,
| and if it doesn't, you can just change the CPU for a
| better one without having to throw all the other,
| perfectly good hardware away.
| ezfe wrote:
| >it'll last you more than two years
|
| An M1 Mac should last double that, easily - so long as
| you don't underspec it. My family has multiple November
| 2020 M1 MacBook Airs that are still working good as the
| day we got them.
| JohnBooty wrote:
| It's probably not as good as an M1, but it'll last you
| more than two years
|
| I don't disagree with the other positive aspects of the
| Framework, but my goodness -- where are you getting this
| idea that a Mac lasts only two years?
|
| 6+ years is the norm for me on Macs.
| CharlesW wrote:
| > _I recommend getting a Framework. It 's probably not as
| good as an M1, but it'll last you more than two years..._
|
| Macs have famously-long usable lives -- my sister uses a
| 7-year-old iMac, for example. The latest macOS Ventura
| supports Macs made in 2017. I'd be very surprised to hear
| about people using 2021 Framework laptops as their daily
| driver in 2026.
| deathanatos wrote:
| ... this literally doesn't mesh with reality.
|
| I've had 3 MBPs, every single one has had _at least_ one
| issue, well before 7 years, usually around 1.5 to 2. The
| first two had battery recalls, the middle one had cable-
| gate, the middle one 's display was also very temperature
| sensitive (it would have glitched lines artifact on the
| screen if the ambient temperature wasn't near 70F), the
| later MBP suffers from keyboard-gate and from constant
| thermal throttling. (Likely because the vents are choked
| with dust, but MBP's user hostile design prevents me from
| opening it up and pushing air through it, which is likely
| all it requires. They hate the user so much they used
| screws _worse than Torx_. I think they 're Pentalobe, but
| don't quote me.)
|
| My current Magic Trackpad is also highly temperature
| sensitive. The "click" will lock up at high temp. (I.e.,
| the trackpad will fight you, if you attempt to click, if
| the ambient temperature is warm.)
|
| > _I 'd be very surprised to hear about people using 2021
| Framework laptops as their daily driver in 2026._
|
| I'm using a Lenovo Thinkpad at about that age. (It is a
| 2017 model, so, 5 years.) The biggest thing wrong with it
| at present is it requires AC power. (The battery
| connection is bad. It lived through two bike crashes,
| though, and I suspect that's a side effect of it. I
| should see if that's repairable, one of these days, but
| I've put up with that for the time, as with COVID, it
| doesn't really travel much anymore.) The TrackPoint(tm)
| is also wonky, but I think that's because sunlight has
| chemically hardened the nib like an old eraser. I have
| more nibs... somewhere. I should look for them or order
| more...
| CharlesW wrote:
| It would be absurd to claim that Macs don't fail or need
| servicing during their usable lives, but you seem to have
| been particularly unlucky in my experience.
|
| > _They hate the user so much they used screws worse than
| Torx. I think they 're Pentalobe, but don't quote me._
|
| Yes, Pentalobe: https://www.ifixit.com/Guide/How+to+clean
| +your+MacBooks+fan+...
| stavros wrote:
| But you're in a thread about how the GP's Mac didn't last
| two years. I'm fairly sure I will be using my Framework
| laptop as my daily driver in 2026, maybe with one
| motherboard replacement. I just switched from my 2017
| XPS, and I do development work. I gave it to my dad, who
| loves it and will probably hold on to it for another few
| years.
|
| It's a bit odd to be saying this about pre-M1 Macs, as
| they were "just" Intel machines, same as everything else.
| Waterluvian wrote:
| A decade with Ubuntu and I get why it's free. I have
| disastrous performance issues with it, for reasons that
| people usually respond, "oh well that's not Ubuntu's
| fault..." but that isn't a great excuse as users do not care
| (unless you aren't intending to attract general users).
|
| Most of the issue is that I have to fight with nvidia video
| drivers every month or two. Something happens and they stop
| operating and it grinds my entire system to a crawl when
| everything is software rendered. YouTube basically kills my
| computer.
|
| When I go with Mac or Windows, the main feature is that they
| have designers to make more than a Potemkin UI, and they care
| about the end to end UX. No, "oh go complain to some other
| vendor."
|
| Ubuntu is very very impressive for free. I certainly
| acknowledge how great that is, and how important that is to
| the ecosystem.
|
| Anyways, sorry about the rant. I'm calming down.
| dm319 wrote:
| I used nvidia with linux >10 years ago. Never again. The
| FOSS philosophy doesn't mesh well with binary blobs and it
| never will.
| Waterluvian wrote:
| The wild thing is that using the Additional Drivers UI is
| what bricked my computer last week. It probably
| downloaded some binaries but it also spent 30 mins
| running gcc compiling something. And then forced a kernel
| headers update but didn't update anything else. Rebooted
| and I have no wifi or bluetooth.
|
| The fix was a reversion and then CLI install of the
| nvidia 515 drivers.
| jacquesm wrote:
| The trick is to disable automatic updates once you have a
| working system. Yes, there is some risk. But at least your
| system will stay as stable as it was when you first
| installed it. Oh, and disable swap and have plenty of RAM.
| Waterluvian wrote:
| 32GB + swap off really does help for sure. I do have
| updates disabled but I admit I am sloppy with not picking
| through what I update. It doesn't help that there's new
| updates basically daily.
| jacquesm wrote:
| Keep an eye on 'snap' it tends to do nasty stuff without
| telling you.
|
| You can disable that too.
| Chinjut wrote:
| Don't MacOS and Unixes have the equivalent of registry hell
| with a million configuration files hidden away in /etc/ or
| /usr/ or wherever, and then having to check where environment
| variables are set and so on? Ideally, almost all of a program's
| configuration settings would be stored in the same folder as
| the program, readily discoverable, and you could just pick
| these things up and move them easily, but in practice, it seems
| to be a pain everywhere.
| thewebcount wrote:
| From a typical user's perspective, macOS puts all Preferences
| files into ~<username>/Library/Application Support/<app
| bundle name> or ~<username>/Library/Preferences/<app bundle
| name>, and they are standard Plist files readable by both
| command line and GUI tools that ship with the system, so
| easily editable and human-readable. From a power-user's
| perspective, it is a Unix system and that part of it is the
| usual mess of Unix config files. I'm definitely a power user
| but rarely have any need to touch a Unix config file on my
| macOS systems.
| pongo1231 wrote:
| NixOS and Guix come close to this with a central spot for
| declaring the entire system state, including program
| configuration and env vars. Now there is still the
| $HOME/.config mess, which home-manager[0] tries to tackle.
|
| [0] https://github.com/nix-community/home-manager
| andrewstuart wrote:
| The registry is uniquely crap because it puts all the
| configuration for everything into some single store - I don't
| know what devilish format lies beneath it, then it stores
| everything as binary keys. Things are not separated strictly
| by application so you end up with a giant pile of
| intermingled goo.
|
| In Linux, no doubt there's alot to get your head around, but
| I've never found things to be a giant pile of spaghetti. The
| challenge Linux has is there's a bajillion ways to do things
| so you have to be pretty experienced to feel confident
| crawling around the tunnels and ventilation ducts.
| anikom15 wrote:
| How long ago did you switch to Mac OS? This sounds like an
| argument from 2004, not 2022.
| andrewstuart wrote:
| When the Intel Mac arrived, so maybe 14 years ago or more?
|
| Are you saying Windows has fixed all these problems?
|
| The registry is still there.
|
| I do actually have some Windows machines I use sometimes and
| recall thinking "still the same" but I can't say that as a
| hard core user, so I'd be interested to hear if Windows is
| now a sleek, reliable multitasker that instantly kills dead
| applications. Nothing will make me OK with the registry and
| the general mess of Windows though - it's like a house
| someone hasn't properly cleaned for 40 yeaes.
| rbanffy wrote:
| > Are you saying Windows has fixed all these problems?
|
| From my own personal experience, no. My machines can become
| unusable from a simple Windows Update.
| trentnelson wrote:
| I feel like if you're bothered simply by the existence of
| the registry, Windows isn't really for you. I get it, a
| little bit -- the OOM killer on Linux just boggles my mind,
| but once you view in context, you can appreciate how we
| ended with it, at a technical level.
|
| But if you think the registry could be replaced with .ini
| files like the good ol' days, that's a pretty extreme hot
| take. If you're open to changing your perspective on what
| the registry is for, how it is designed, and why it's
| necessary, read any of the Windows Internals books.
| ChoGGi wrote:
| > Add to all that, Window slows down over time - again, the
| periodic reformat and rebuild is part of life on Windows.
|
| My windows install is from 201*, it was an upgrade from win7,
| and switched from an i7 to a ryzen. I do clean out the
| registry/startup/task scheduler on occasion.
| Maursault wrote:
| > My windows install is from 201*
|
| The early 3rd century was the best era for Microsoft with
| Windows Severan.
| andrewstuart wrote:
| The early 3rd century was an exciting time for computing.
| The big issue back then was Roman numerals were hard to
| convert to hex and binary.
| rbanffy wrote:
| Back then mainframes had specialized hardware to deal
| with them.
|
| Note: the other day I read ICL mainframes had specialized
| instructions to deal with pre-decimal pounds.
| int_19h wrote:
| The widespread adoption of CISC architectures solved this
| problem, since many of them included special-purpose BCR
| (Binary-Encoded Roman) instructions.
| WillPostForFood wrote:
| This is also why I ditched Windows, about 15 year ago. But
| honestly, I get more ui freezes and beach balls today with
| Monterey than I do with Win 10. Windows has been getting better
| while MacOS has been slipping.
| w1nst0nsm1th wrote:
| 24 cores CPU and the guy is still in a wordpress domain name ?
| dang wrote:
| Discussed at the time:
|
| _24-core CPU and I can't move my mouse_ -
| https://news.ycombinator.com/item?id=14733829 - July 2017 (499
| comments)
| dm319 wrote:
| Sounds like Windows needs this 200 line kernel patch that sped
| things up for linux in 2010 [1]
|
| "The patch being talked about is designed to automatically create
| task groups per TTY in an effort to improve the desktop
| interactivity under system strain."
|
| "Tests done by Mike show the maximum latency dropping by over ten
| times and the average latency of the desktop by about 60 times."
|
| [1] https://www.phoronix.com/review/linux_2637_video
| malfist wrote:
| Hyperthreads aren't real CPU cores, claiming that your 48
| hyperthreads were "only" 50% utilized means all the real cores
| under the hood are fully utilized.
| ilyt wrote:
| Nope, all depends on type of load.
|
| HT is an opimization to context switching but if your code
| running on both utilizes different parts of core (say one loads
| some memory while others does some math), you can get speedup
| that's above savings from not having to context switch.
|
| But early on it wasn't really that well optimized so you
| might've had OS put 2 threads on 2/1 HT/core while other core
| sits idle
| CoastalCoder wrote:
| > Hyperthreads aren't real CPU cores
|
| I can't think of a good principled reason to say SMT cores
| aren't "real".
|
| I'm assuming the answer isn't "because they share some
| computing stuff". What I think you'd call "real" cores also
| share resources like L2/L3 caches, sometimes DMA engines, etc.
|
| And IIRC, each Intel SMT (hyper-thread) unit has its on
| instruction pointer and (non-SIMD?) register set.
| fmajid wrote:
| On AMD, yes, but Intel Hyperthreading is not real SMT.
| toast0 wrote:
| > And IIRC, each Intel SMT (hyper-thread) unit has its on
| instruction pointer and (non-SIMD?) register set.
|
| I believe the SMTs share the register rename storage, which
| I'd say is the register set more than the 'architectural
| registers'
|
| But I'd say the reason they're not real is because they don't
| increase the maximum instructions per clock. With many loads,
| they do increase the average instructions per clock, but they
| don't let you do anymore work if you've got a fully tuned
| load that uses all the computing resources.
| eloff wrote:
| In reality you never have a finely tuned load that uses all
| the resources all of the time. Processors spend a lot of
| time waiting for memory, so hyperthreading allows for
| better utilization of compute. It's rare to have a workload
| that benefits from turning it off, and in those cases it's
| usually because the hyperthread is hurting the cache hit
| rate enough to offset the gains.
| hinkley wrote:
| Both threads are waiting on the same memory pipeline. The
| actual performance has always lagged behind the theory
| kevin_thibedeau wrote:
| If one thread has to hit main memory but the other one
| can get what it needs from L1 cache they aren't competing
| for the same resources.
| eloff wrote:
| But not the same memory operations. Unless your code
| fully saturates the memory bandwidth, which is rare, you
| get some gains here.
| AdrianB1 wrote:
| It is almost never about saturating the memory bandwidth,
| but waiting to load instructions and data from memory.
| That wait time counted in computer cycles is huge.
| eloff wrote:
| Yes, that's precisely why hyperthreading is such a good
| deal.
| MauranKilom wrote:
| I recently checked whether an ugly hack I implemented
| years ago for 30% performance gains ("halve the default
| OpenMP thread count at start of computation and restore
| it afterwards" -> effectively, disable hyperthreading)
| was still necessary. It's now apparently a 3x performance
| gain... All because I'm saturating memory bandwidth. I
| don't know whether to be happy or sad...
| zamadatix wrote:
| I agree with this stance. It's the same as branch
| prediction, out of order execution, or anything else about
| computing efficiently.
| FpUser wrote:
| Many years ago a customer on a single core computer had
| problems of heavy video stutter in my product. It was
| multithreaded and ran as I recall 5 threads (GUI, video
| decoding, 3d pipeline, device control and computation).
| Others did not have this problem. After investigation it
| turned out that said customer had hyperthreading disabled
| in BIOS. Enabling it fixed the problem instantly.
|
| So "real" or not but from my experience HT does work to the
| benefit.
| hinkley wrote:
| I don't know how many hardware revisions Intel went through
| where every benchmark said hyperthreading was slower than
| turning it off, but it was a lot. It became Lucy's football
| at some point.
|
| And in these days of post-Dennard scaling, you have thermal
| throttling, so idle cycles aren't actually idle, they're
| allowing the heat sink to catch up with heat production.
| bakugo wrote:
| > I can't think of a good principled reason to say SMT cores
| aren't "real".
|
| It really depends on your definition of "real", yes you can
| treat them like "real" independent cores but that's not ideal
| for performance because under the hood they're not actually
| independent. Your operating system is aware of this and will
| often avoid scheduling two tasks onto the same physical core
| unless it has to. If you have 20 logical cores (10 physical
| ones with hyperthreading) and 10 tasks to execute, the OS
| scheduler will usually allocate one task to each physical
| core and leave the other logical core idle.
| Sohcahtoa82 wrote:
| I did an experiment and effectively proved this to myself
| many years ago.
|
| I had just upgraded to an i7-3770K (8 threads, 4 cores)
| from a Core 2 Quad (4 threads, 4 cores). I did a POV-Ray
| render several times using 1, 2, 4, and 8 threads. 2 was
| nearly double the speed of 1, 4 was nearly double the speed
| of 2, but 8 was only about 15% faster than 4.
|
| To ensure I wasn't bottlenecking RAM at that level, I tried
| again with 2 threads, but forced both threads onto a single
| core, and it was only 15% faster than 1 thread.
|
| That was all the proof I needed of how you really can't
| treat two CPU threads as two cores.
|
| That said, I've never personally found an instance where
| allowing a processes to span all CPU threads actually
| reduced performance, and I'm not sure I've ever seen a
| real-world case where it does. It's usually something
| contrived.
| duffyjp wrote:
| When I bought my current desktop the two CPUs I was
| looking at were the i7-9700K and i9-9900K. This was the
| generation where intel went from 6 cores with HT to 8
| cores w/o HT for the i7. The i9 has 8 cores with HT.
|
| I liked the idea of the i7 because without HT you have a
| real picture of how utilized your CPU is. If it says 100%
| on a core it's 100%. I ended up going with the i9 though
| when a promotion was too good to pass up.
|
| When I got it I ran Cinebench both with and without HT
| enabled in the BIOS and it made a decent impact so I left
| it on.
| jeffbee wrote:
| That's one use case. SMT is not designed to address it.
| POV-Ray will saturate your execution resources in the
| core and adding another frontend doesn't change the
| facts.
|
| SMT is designed to hide memory load latency. In this use
| case it is completely brilliant. You will get 2x speedups
| with hyperthreading when randomly accessing memory.
| MauranKilom wrote:
| > You will get 2x speedups with hyperthreading when
| randomly accessing memory.
|
| ...unlesss you access so much memory (while doing
| relatively little compute on each piece) that
| hyperthreading just causes more cache invalidation.
| 323 wrote:
| 4 wheel drive is also not real, because under the hood they
| share the same engine.
| leephillips wrote:
| Only on those ancient internal combustion computers.
| Oxidation wrote:
| Ctrl-F in a 10MB PDF in Adobe DC lags when typing while (I guess)
| it builds the search suggestion index. On an i9 11th gen with
| over 20000 CPUmark, and 64 GB of RAM. Madness.
| Baeocystin wrote:
| I hold out forlorn hope that someday my modern workstation will
| achieve the responsiveness and fast boot times of my Commodore
| 128. Not joking in the least.
| logicallee wrote:
| I have a long break over the holiday and am thinking of putting
| a software project out.
|
| Do you think I should consider making it a priority to code in
| a fairly low-level programming language (e.g. Rust) without
| overhead, and count cycles so that most tasks are done within a
| single screen refresh?
|
| I can't make the rest of users' systems more responsive but I
| could make my own software as fast and efficient as possible.
|
| The other alternatives are Python, which would make it easier
| to ship large features but would come with a large overhead
| (full interpreter) since it's an interpreted language.
| einpoklum wrote:
| > Do you think I should consider making it a priority to code
| in a fairly low-level programming language (e.g. Rust)
|
| Maybe. Premature optimization is said to be the root of all
| evil...
|
| But at the same time - the assumption that everything will be
| easier and faster in Python rather than Rust or C++ is often
| invalid. Sure, for smaller scripts it almost always is like
| that, but once your app grows, this may stop being the case.
|
| Start with a language that's convenient for you and with
| which you can release an initial version. Then get an
| understanding how it behaves in terms of performance, and
| draw your conclusions.
|
| > as fast and efficient as possible.
|
| Responsiveness is not the same as speed or efficiency. Of
| course it's important to be fast and efficient, but it is
| even more important to not just start crunching numbers and
| ignore the user and the rest of the system.
|
| Do your hard lifting asynchronously and have a thread
| attending to user input and your UI (or even different
| threads for these two tasks). And this is easier said than
| done!
|
| Also remember you'll have to try and work around delays and
| slowdowns due to other apps and the (non-realtime) OS.
| Specifically, you might have to play with thread scheduling
| and I/O priority (although - that's usually the user's rather
| than the app's job).
|
| Additional notes:
|
| * Also consider C++; it has some advantages and disadvantages
| relative to Rust (which I obviously will not get into), but
| it has seen a whole lot of progress in recent years, in
| particular w.r.t. the ease of doing many things which used to
| be painful.
|
| * If you think of Rust as low-level, then your head must be
| in the clouds... :-P
| akiselev wrote:
| _> Maybe. Premature optimization is said to be the root of
| all evil..._
|
| The _full_ quote, because it always gets butchered to
| "premature optimization is the root of all evil":
|
| _Programmers waste enormous amounts of time thinking
| about, or worrying about, the speed of noncritical parts of
| their programs, and these attempts at efficiency actually
| have a strong negative impact when debugging and
| maintenance are considered. We should forget about small
| efficiencies, say about 97% of the time: premature
| optimization is the root of all evil. Yet we should not
| pass up our opportunities in that critical 3%._
| shadowofneptune wrote:
| Cycle-counting is useless on modern workstations, since
| different processor are used in each. I don't see how the
| choice of language is significant either, as long as it meets
| your goals for responsiveness. Goal could be instead to limit
| latency where possible (measuring time from click to
| completed action is easy with a framework), or communicate to
| the user when an action will take a noticable amount of time.
| szundi wrote:
| Agreed. The 2 choke points you optimize in algo returns the
| loss on choosing an otherwise better lang/environment for
| productivity.
|
| Sometimes not though, like startup times, but there is not
| so many use cases that this counts, like 1password starts
| slower with each release.
| AlexanderDhoore wrote:
| I'd do it in C, but that's just me. If this is a one-person
| project you can hold you code to a high standard. Clean
| standard C11 with all warnings turned on (-Wall Wextra
| Wpendantic Wconversion). Write unit tests. Run them with
| valgrand/sanitizers. Use clang-format. Build with multiple
| compilers (GCC/clang/MSVC). ...
|
| EDIT Not many hackers on hackernews apparently.
| ratorx wrote:
| I'm curious as to the upside of C, is it mostly just a
| familiarity thing?
|
| Holding your own code to a high standard is great, but
| wouldn't it be nicer if you could offload more of that into
| the tooling and spend more time on the problem or making
| the code even cleaner?
|
| Also as a side note: I always find it funny that a flag
| that represents all warnings doesn't actually turn on all
| warnings.
| robinsonb5 wrote:
| For my own projects I use C because I know it, but also
| because I know and trust the ecosystem. I seem to have
| developed something of a software-survivalist mentality,
| so I like to know that I can build my project five years
| from now without worrying about whether some remotely-
| hosted dependency isn't there any more. (I'm not claiming
| that newer, more trendy languages necessarily fail this
| test - just that I don't know and trust their ecosystems
| well enough to be sure.)
|
| C also has the advantage that there are many, many
| different compilers targeting many, many, /many/
| different architectures. My own favourite is VBCC, which
| is lightweight enough that I was able to write my own
| backend for my own toy CPU project, and even build the
| entire toolchain - assembler, linker and compiler - under
| AmigaOS.
| int_19h wrote:
| Out of curiosity, when you considered the compilers to
| use for your CPU project, did you look at pcc? And if so,
| how would you say vbcc compares, in terms of ease of
| porting to a new arch?
| ratorx wrote:
| I think the remotely hosted dependency problem and
| ecosystem thing is not that big of a deal all the time,
| but if the project involves atypical OS and
| architectures, then C makes sense. I think it's still
| possible to do these in other languages, but that's just
| another familiarity gap to add to the existing set.
|
| For the remotely hosted dependency thing, I think it's
| pretty easy to vendor dependencies in most realistic C
| contenders, and a really simple litmus test is just
| yanking your network cable and doing a fresh build.
|
| The ecosystem thing can be a bigger deal, but again it
| really depends on the problem domain. There are lots of
| high quality, non-C libraries for C to always be a clear
| winner. I think it's more important to take a step back
| and make sure whatever language you pick is well suited
| to the task, rather than assuming any individual one will
| always be. Knowing multiple languages is handy for this,
| since that's more ecosystems that you can pick from,
| rather than just tying yourself to a single one.
| robinsonb5 wrote:
| > The ecosystem thing can be a bigger deal, but again it
| really depends on the problem domain.
|
| Yes, absolutely - and of course C isn't immune to
| ecosystem problems, either. I remember the pain of
| working with GNU autotools back in the mid 2000s - in
| fact it's probably that experience (plus trying to use
| bleeding-edge tools written in Python!) that left me so
| cautious about external dependencies today.
| nrdvana wrote:
| I found the opposite in a very real-world analysis of my
| hobby project to build a digital dashboard for my DeLorean.
| I spent 5 years making very slow progress with C++, and
| then switched to perl, started mostly from scratch, and
| finished in a year. I gave a talk about this exact topic at
| YAPC 2014: https://youtu.be/SERH3_gZOTo?t=1018 The CPU
| usage on the embedded PC went from 15% to 40%, but in the
| grand scheme I'd rather have it finished and pay a little
| more for the hardware.
| amluto wrote:
| This is usually the wrong approach. Make sure you don't do
| computations that block the UI, avoid accidentally quadratic
| behavior, and make sure you process UI events promptly. You
| can do this is pretty much any language, with minor caveats:
|
| Some languages (e.g. Haskell) make it easy to write code that
| does more computation than intended. If you use one of these
| languages, make sure you know what you're doing.
|
| If you use a language with a truly horrible GC, you might
| experience excessively long pauses. Similarly, if you produce
| too much garbage, you might have issues.
|
| If you use a language that can't multithread properly (sigh,
| Python), moving tasks off thread is a mess.
|
| Otherwise, one can write perfectly responsive software in
| just about any language.
| phaedrus wrote:
| I worked with a brilliant engineer who had previously worked at
| one of the major hard drive manufacturers. He told me about a
| project he'd worked where the disk manufacturer had their
| firmware writers collaborate with low-level OS programmers to
| significantly speed up modern PC boot times. The conclusion was
| yes they could technically do it, but they found so many
| peripherals and device drivers that relied on the boot being
| slow (either intentionally or unintentionally - e.g. hardware
| or software race conditions, device drivers not actually making
| sure the device is ready yet, etc.) that there was "no point."
| kabdib wrote:
| I've seen code that
|
| (a) issued an async read
|
| (b) did some computation
|
| (c) used the buffer filled in by that async read
|
| ... without actually seeing if the read completed. Hilarity
| ensued when the CPU got faster. This was in stuff that
| shipped to hundreds of thousands of customers.
|
| If you're having a good day, you can definitely address that
| problem by reading device drivers for a few hours.
| nemacol wrote:
| I feel the same way about TV. I miss the ability to quickly
| flip through channels.
|
| When I was younger and my family had our first internet
| connection my dad said "One day internet webpages will load
| like changing channels on the TV - click click click. instant
| page loads"
|
| Today TV soo much slower and webpage are... well... you know.
| ant6n wrote:
| So the prediction came true - webpages and tv channels load
| at the same speed.
| MayeulC wrote:
| I played around with the `dillo` web browser a couple years
| ago. It doesn't support javascript, but it was oh so amazing
| to experience it as you describe.
| officeplant wrote:
| I still love using Dillo or w3m to browse a simpler web at
| times.
| doublepg23 wrote:
| Not sure if you're familiar (it's made the rounds a few
| times) but the Gemini Protocol (HTTPS replacement) and
| corresponding Gemtext format (Basically Markdown not even
| HTML really) is very cool internet space.
| https://gemini.circumlunar.space/
| mixmastamyk wrote:
| Can still be done if all you want is a command-line to come up
| and be responsive.
|
| Most folks want web, email, images, and even a bit of security
| from their computer today. Could always be faster, but I think
| the days of "bam!" ready are past due to those requirements.
| Unless the computer is only sleeping, like an iphone for
| example.
| throwaway0x7E6 wrote:
| web, email, images and a bit of security are not the reason
| windows UI is laggy as fuck
| idonotknowwhy wrote:
| I agree. Around 2008 when I got my first SSD installed,
| windows 7 and PCLinuxOS2007 would open apps like Word
| instantly. You'd click and it'd be there within 100ms.
|
| Now with windows 10 on a much faster pc, clicking apps like
| Firefox, the start menu, word take seconds to load.
|
| I recently fired up my windows 7 VM to mod an old game
| console and it was exactly how I remembered. You click
| something and it's instantly opened.
| ianlevesque wrote:
| Those things don't preclude responsiveness though. Modern
| software is sitting on top of mountains of inefficiencies and
| legacy baggage. This was found just months ago
| https://arstechnica.com/gadgets/2022/09/20-year-old-linux-
| wo... "A bit of security" is also quite apt, since there's
| huge room for improvement there too. I wish I could find a
| way to get paid to improve all this. Currently I'm only doing
| it for mobile apps.
| _Algernon_ wrote:
| >Most folks want web, email, images, and even a bit of
| security from their computer today. Could always be faster,
| but I think the days of "bam!" ready are past due to those
| requirements. Unless the computer is only sleeping, like an
| iphone for example.
|
| Sure, but a modern computer also has orders of magnitude more
| processing power than devices that only ran a command line.
| There is no reason that we cant have both, except
| incompetence and/or bad economic incentives.
| db48x wrote:
| While I agree that incompetence and bad incentives are
| ever-present, and that all software can be optimized by
| application of a little elbow grease, I disagree that these
| are the only reasons.
|
| For example, properly displaying text now requires having a
| copy of at least the most important parts of the Unicode
| standard in memory. Things like knowing if a character
| occupies one, two, or many character cells are very
| important for even a simple text terminal. Word splitting,
| kerning, shaping, bi-directional text display, the number
| of possible refinements grows without bound and all of them
| need metadata about each and every character. Your average
| web browser has megabytes of the stuff just sitting around
| in memory so that it is ready as soon as a character has to
| go up on the screen. Older computer just didn't have that
| kind of memory to spare.
|
| If you want the old-school experience you can still boot
| straight into the Linux Console, which still thinks that
| there are only 256 characters. It seems to be reasonably
| snappy.
| Gigachad wrote:
| The average user doesn't even boot the computer. It's just
| always on and wakes pretty much instantly.
| anikom15 wrote:
| Not a C64 user, but I did use Apples, Ataris, and IBMs. Booting
| to BASIC or a cartridge was fast. Booting to a floppy not as
| much.
|
| Reading a tape? That took several minutes.
| dijit wrote:
| The boot was fast on the c64. Essentially instant.
|
| It just dumped you into a prompt though, and loading any
| program was really quite painfully slow.
| jwilk wrote:
| You may also like "24-core CPU and I can't type an email" from
| 2018:
|
| * part 1: https://randomascii.wordpress.com/2018/08/16/24-core-
| cpu-and... https://news.ycombinator.com/item?id=17780127 (313
| comments)
|
| * part 2: https://randomascii.wordpress.com/2018/08/22/24-core-
| cpu-and... https://news.ycombinator.com/item?id=17824575 (99
| comments)
| NobodyNada wrote:
| In the follow-up blog post
| (https://randomascii.wordpress.com/2017/07/27/what-is-windows...)
| he uses a sampler to try to find the bottleneck by looking at CPU
| instructions, but concludes:
|
| > But the main thing I always realize when using this technique
| is that modern CPUs are weird and confusing. Because CPUs are
| massively out-of-order and super-scalar it is not at all clear
| what it means for a sampling interrupt to hit "on" a particular
| instruction. If an instruction is particularly expensive then
| samples are more likely to hit "near there" but I'm sure where
| "near there" actually is:
|
| > If there are three instructions executing simultaneously when
| the interrupt fires then which one "gets the blame"?
|
| > If a load instruction misses in the cache and forces the CPU to
| wait then will the samples show up on the load instruction, or on
| the first use of the data? Both seem to happen.
|
| > If a branch is mispredicted then will the samples show up on
| the branch instruction or on the branch target?
|
| > What's going on with the expensive cmp instruction on line 24
| of the spreadsheet?
|
| > If anyone has a good model for what happens to the CPU
| pipelines when a sampling interrupt happens I would appreciate
| that. Ideally that would explain the relationship between
| clusters of samples and expensive instructions.
|
| I have a distinct memory of reading a blog post probably 5-ish
| years ago where someone did just that. The author started with
| some microbenchmarks of very tight loops, and used some sort of
| profiler/perf counter tool that measured hit counts for each
| instruction of the loop. Then, they went into a deep dive into
| analyzing the instruction throughputs and latencies and
| dependency chains to demonstrate how bottlenecks at the CPU level
| manifested as clusters of samples, and how to use this
| information to optimize the loop.
|
| Does anybody else remember this post, and possibly where I can
| find it? I've been in a couple situations where it would have
| been tremendously helpful, but I just haven't been able to dig it
| up.
| formerly_proven wrote:
| Sounds like the work of Agner Fog.
| tinglymintyfrsh wrote:
| Thermal throttling, dirty fans, poor process isolation and
| scheduling, and so forth.
| yazzku wrote:
| I fell off the chair when I read the headline. I get that
| software runs insanely fast on modern hardware and that often,
| the naive solution works with acceptable performance. But boy --
| can we not set the bar as low as "barely responsive"? If your
| thing doesn't run on a Raspberry PI, it's probably garbage.
| 1970-01-01 wrote:
| Tangent: Moving the mouse made Windows 95 faster
|
| https://www.pcgamer.com/this-theory-suggests-wiggling-the-mo...
| ArmandTanzarian wrote:
| At 40 this behavior is ingrained in me and influences my
| behavior while using a computer to this day.
| cassianoleal wrote:
| Back in the early 00s my cousin had a modem that would only
| transfer data if either the mouse or the keyboard was in use.
| actionfromafar wrote:
| So it wasn't just my imagination that installers became faster
| when doing that...
| PaulHoule wrote:
| Moving the mouse is the worst case scenario for a deep multicore
| processor because (1) it is a single-threaded latency sensitive
| task, (2) there are 23 other cores that can grab a lock and
| prevent the 1 core that matters from doing its job in a timely
| manner.
| hulitu wrote:
| So the 23 cores are there only to starve the 24th ? Sounds
| almost human.
| baq wrote:
| Where are the mouse coprocessor equipped computers?
| bluescrn wrote:
| Hardware sprites (and presumably interrupts) made the Amiga
| mouse pointer move fluidly and responsively even when the CPU
| was busy. No complex graphics pipelines or laggy LCD screens
| to add further latency back then either.
| mrybczyn wrote:
| I do miss aiming a particle accelerator at my brain as a
| HCI method.
| ilyt wrote:
| It was just form of 2D acceleration.
|
| We even see it now, sometimes called "hardware cursor" in
| various games settings, althought pipeline is much
| longer.
|
| Just that old small hardware had little to no memory
| protection and very tight integration so stuff like that
| could be done directly instead of going thru many layers
| of abstraction
| MauranKilom wrote:
| Not sure if you missed the point or I'm missing yours,
| but the post you replied to points out that CRT displays
| sound insane in a certain light...
| Someone wrote:
| You can do it with very little. Prime example: https://www.
| folklore.org/StoryView.py?project=Macintosh&stor... drawing
| a mouse pointer on an almost stock Apple II, flicker-free
| because drawing is synced to the vertical blank interval,
| even though the hardware cannot see when that happens (that
| part I don't quite understand; I can see them detecting
| 'end of screen' on an almost blank screen and programming
| the timer to generate a periodic interrupt at about the
| screen redraw frequency, but wouldn't the VBL and the 6522
| interrupts drift away from each other over time?)
| robinsonb5 wrote:
| Indeed - it's no deep magic, "all" you have to do is update
| the sprite's position from within the very same interrupt
| which reads the mouse counters. Oh, and make sure that
| nothing involved in that process can be paged out, ever.
| (The Amiga made sure of that by not supporting virtual
| memory!)
| HPsquared wrote:
| Optical mice themselves can have quite a complicated
| processor onboard. Luckily the image processing isn't done on
| the CPU/GPU.
|
| I wonder if anyone ever sold a "software optical mouse".
| ycombin23918 wrote:
| > I wonder if anyone ever sold a "software optical mouse".
|
| You could if you really want to...
|
| https://8051enthusiast.github.io/2020/04/14/003-Stream_Vide
| o...
| formerly_proven wrote:
| Mouse cursors are mostly handled in hardware. GPUs composit
| the cursor during scanout, so all the OS has to do is
| calculate the new coordinates of the cursor and tell the GPU
| about them.
| winter_blue wrote:
| > Mouse cursors are mostly handled in hardware. GPUs
| composit the cursor during scanout, so all the OS has to do
| is calculate the new coordinates of the cursor and tell the
| GPU about them.
|
| Is this true on modern Linux DEs (e.g. on KDE Plasma)?
|
| Is it also true on Windows and macOS?
| the8472 wrote:
| This is fairly basic functionality. Windows and wlroots-
| based compositors have it at least. I'm reasonably
| certain that other major compositors have it too.
| salawat wrote:
| Did you check?
|
| I tell my QA people all the time: If you come to me with
| "I think" or "I believe", it sounds like you've got some
| reading to do.
| the8472 wrote:
| I didn't write "I think" or "I believe".
|
| If you want to know my epistemic status: I know about
| windows based on observable surface behavior and bugs
| related to accelerated cursors, but I haven't looked at
| the source. I know about wlroots because I saw the pull
| requests related to that and a flag to disable it in
| sway. The last statement regarding other platforms was an
| educated guess based on gfx card history: accelerated
| overlays are an ancient feature present in a lot of
| hardware, not some newfangled niche feature.
|
| And I'm not one of your QA people.
| int_19h wrote:
| I don't know about other platforms, but in Windows, it
| had been true >20 years ago, before the desktop was even
| composited. Some fullscreen games also relied on this
| functionality, and sometimes you had an option in game
| settings to switch between hardware-accelerated cursor
| and manually drawn one (because the former could be buggy
| with some video drivers).
| chrsig wrote:
| With regard to latency sensitivity, with so many cores
| available, a single core could be dedicated to processing mouse
| input. Of course, if there's a lock in the way that's held,
| that's still a problem.
| astrange wrote:
| Or if it needs code that's paged out or all cores are thermal
| limited or the GPU hung. CPU time usually isn't the limiting
| factor.
| PaulHoule wrote:
| For a modern system like Wayland or WDM, the display
| compositor gets rectangles of pixels from the applications,
| copies those into a big rectangle it sends to the rasterizer.
| Just before it does that, it draws on a mouse cursor. It also
| has to communicate with the applications about what image to
| draw so you have to deal with multiple threads no matter
| what.
|
| (Unless you go back to the late 8-bit era where the cursor
| might be a just a hardware sprite that can be moved around by
| writing a few bytes.)
| Rusky wrote:
| I believe the mouse cursor is still often a hardware sprite
| today.
| db48x wrote:
| Almost 100% guaranteed, but it is still possible for the
| OS to be delayed in sending it the coordinates. Of course
| that means that the OS is badly written.
| yamtaddle wrote:
| By these standards, the only well-written operating
| systems I've ever seen are BeOS and QNX/Photon. Probably
| iOS (at least, older versions of it) deserves to be on
| the list, despite mouse use being atypical.
|
| Which... yeah, that actually might be true.
| mijoharas wrote:
| I can say for sure this is true on sway (wayland) because
| while messing around seeing if the proprietary nvidia
| driver finally works yet (when will I learn... for anyone
| curious nvidia is still nvidia) one of the things I had
| to do was manually disable hardware cursors.
| Pxtl wrote:
| From reading it over the root cause was in a massively-
| multiprocess application. In general this is the usual problem of
| "on windows use threads not processes for ephemeral parallel
| tasks" right?
| kevingadd wrote:
| There are also just some workloads that will saturate things.
| If you hit the mmap infrastructure hard enough on Windows you
| can saturate the kernel and your mouse cursor will stop moving,
| I managed to do it with a custom key/value store written in C#
| once I spun up enough threads hitting mapped files at once.
|
| I would assume that on win10/11 (this was a while ago) it is
| harder to saturate a modern machine, though, especially if you
| lower the i/o priority of your process.
| paultopia wrote:
| Ask me about how my couple-generations-ago ipad pro (just before
| the M1) sometimes randomly freezes when I try to scroll a pdf...
| Razengan wrote:
| Why don't computer architectures have a separate CPU dedicated to
| the OS/GUI?
___________________________________________________________________
(page generated 2022-12-22 23:01 UTC)