Earlier quoted context omitted.
Try running Google Maps on your 133Mhz Pentium.
Google Maps runs like crap on my current desktop. That's precisely the problem!
Is your current desktop at 133Mhz Pentium? It runs perfectly well on my 2015 Macbook Pro!
Almost everything on computers is perceptually slower than it was in 1983 (2017)
361–370 of 388 posts
Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)
#362Earlier quoted context omitted.
I've been using Linux since... oh, 1999 or 2000, and I've never seen a Linux GUI desktop I'd describe as snappy and responsive. The best I've ever achieved is "not incredibly clunky" and that only by ensuring the graphical interface basically did nothing but run the current application or two I had open. I've seen BeOS, QNX, and (Apple) iOS graphical operating systems/environments that were consistently, remarkably s…
I have to disagree. The comparison you make is unfair. I experienced QNX and Beos too. But what could you really do with it out of the box, compared to a full blown Linux-distro? The 'feeling' of snappiness is a matter of carefully choosen defaults IMO. Almost nobody does that anymore. So have this lowest common denominator, and mostly crappy tools to change them from within the GUI, or have to dive down in the cessp…
shrug I've had Linux desktops across Debian, Mandrake, Gentoo, Ubuntu, and maybe some others. Oh I think Fedora in there somewhere. Gentoo and the first few years of Ubuntu (pre-Pulseaudio, basically, though it's not the only reason it suddenly got worse right around that time) were the only ones that felt like they weren't built on some kind of horrid Jenga tower always on the verge of toppling over, but in Gentoo's case that's only because I placed all the pieces myself. And it's never felt any "faster" or more responsive than Windows unless stripped down to bare bones on the UI side. And God did X used to crash a lot. At least Xorg's mostly better on that front, but then Windows doesn't BSOD a couple times a day anymore either.
[EDIT] oh as for BeOS, it ran a lot of the same junk I ran on Linux just fine. Better, really. It wasn't suitable for a server, but that didn't and doesn't really matter for one's desktop OS experience. Especially these days—can it run a VM (as one supposes any modern BeOS-alike could, because why not)? Cool, then I can run most any deployment target I like on it.
Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)
#363Earlier quoted context omitted.
The increase in video RAM requires more of the CPU and GPU. Downloading and displaying a JPEG at today's resolution requires more of everything, not just video RAM. Anyway, If you come to over to the server side you can see other code that performs very differently than it could have back in 1983. Sometimes unimaginably different — how would a service like tineye.com have been implemented a few decades ago?
The point I'm making is that my desktop PC sitting in my office now does have more of everything compared to my 133MHz PC from 1995. Not everything has scaled up at the same pace, sure, but literally every piece of hardware is better now. People talk about difference in resolution and color depth? 640x480x16 isn't that much less than 1920x1080x32. My current resolution has 13 times more data than my 1995 one, and my…
Is it OS and SDK bloat? Where do you think most of the cruft is coming from?
Let's say I had a given LOB application written in vb6, c#.net winforms, heck, maybe even WPF. All single-threaded.
If I re-wrote the same application (features, UI, still single-threaded) in native Win32, would that improve the latency?
Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)
#364Earlier quoted context omitted.
Games have huge advantages of constraint of application that mapping applications don't. You can get pixel perfect scrolling when you constrain the max rate the user can pass through the dataset, you deny them random access into the dataset, your dataset isn't trying to represent a space the volume of planet Earth, etc. There's a huge gulf between the use cases you're comparing here, and I don't believe for one secon…
Illl ignore the pedantic part since it was just an analogy, if it doesn't work for you there is little to talk about. > Games have huge advantages of .... I have thoughts like that but I consider them "making up excuses". You don't have to see it that way but I can't see someone fix a problem by making up excuses for it to exist. For me it is just like you can always come up with an excuse not to do something. 8 giga…
I'm still happy with the configuration we have where my map is a little slower than maybe I'd like it to be (though honestly, I just loaded maps.google.com and moused around randomly and... it's fine? Certainly not so slow I'm bothered by it) but the mapping app also can't crash my computer due to the three layers of abstraction it's running on top of. Because that would suck.
If you're curious where the time goes, btw... Most of the visible delay in Google Maps can be seen by popping the browser inspector and watching the network tab. Maps fetches many thin slices of data (over 1,000 in my test), which is a sub-optimal way to do networking that adds a ton of overhead. So if they wanted to improve maps significantly, switching out for one of the other protocols Google has that allows batching over a single long-lived connection and changing the client and server logic to batch more intelligently could do it. I doubt they will because most users are fine with the sub-three-second load times (and engineering time not spent on solving a problem most users don't care about is time spent on solving problems users do care about). You're seeking perfection in a realm where users don't care and claiming the engineers who don't pursue it "suck;" I'd say those engineers are just busy solving the right problem and you're more interested in the wrong problem. By all means, make your mapping application perfect, as long as you understand why the one put out by a company with a thousand irons in the fire didn't.
Also, I think the analogy was great, but you reached the wrong conclusion. ;) That is how large-scale engineering works. Scheduling becomes the dominant phenomenon in end-to-end performance. Games have huge advantages on constraining the scheduling problem. General-purpose apps do not. Hell, to see this in action in a game: Second Life's performance is crap because the whole world is hyper-malleable, so the game engine cannot predict or pre-schedule anything.
Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)
#365Earlier quoted context omitted.
Huh. I'd say the examples are perfectly good and on-point. While dealing with autoexec.bat and random BSODs wasn't fun, it's entirely orthogonal to the fact that a DOS-era POS still offers orders of magnitude better UX than current-era browser POSes, or than most web apps for that matter. It also doesn't change the fact that Google Maps is very bad at being a map . It's entire UI flow is oriented for giving turn-by-t…
What makes Google Maps bad? My computer in 1983 didn't have a map application at all, how can Google Maps possibly be bad compared to that? And if I had had a map application (I'm sure they existed) it would have taken several minutes to load from cassette tape. That's not faster than Google Maps, either perceptually or objectively.
I did have map applications in 1993.
Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)
#366Earlier quoted context omitted.
The page in question discusses latency in terminals, not how it compares to performance of previous generations. That being said, it also seems to have to pull in the 99th percentile behavior in order for the timings to be an issue, and even then it's not horrible; it doesn't get actually "bad" until you consider the worst performance (99.9th percentile) of the worst performer (st). It seems overly picky to me.
Today's terminal has some difference, the fonts should look anti-aliased, flickering should be as minimal as possible, should be able to theme it based on preference. One terminal able to support so many different terminal type VT100, rxvt, and still need to perform fast. I have worked enough on text only and 256 graphics terminal in yester years and feel today is still better. Another case, Google maps is a bad exam…
The argument is that a terminal shouldn't be slower given the increase in computing power by several magnitudes. Maps has its own scalability challenges, but a terminal doesn't need a live network connection and isn't/shouldn't be maintained by 100 developers who each only know a small bit of the codebase and step on each others' toes.
Given some corrections, we certainly have the capability to build terminal workflows with less latency. So there is nothing wrong with pushing the community forward.
It's not a matter of nostalgia or just being content with the way things are. People used to argue vehemently against the features we enjoy today such as autocomplete and advanced theming, but a few people kept their heads down and made it happen anyway, because it was The Right Thing.
Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)
#367Earlier quoted context omitted.
The time that matters isn't how long it takes to restart the app; it's how many hours of changes just got eaten because the app crashed and the data was either resident in memory only or the crash corrupted the save file (the latter scenario, again, being more common in the past where correctly shunting the right bytes to disk was a dance done between "application" code and "OS toolkit" code, not the responsibility o…
OTOH, lower runtime performance of modern apps eats into how much people can produce with them - both directly and indirectly, by slowing the feedback loop ever so slightly. While there are couple of extra layers of abstractions on our systems that make them more safe and stable, hardware has accelerated far more than just to compensate. Software of today needs not to be as slow as it is.
In general, people will tradeoff fixed predictable cost to high-variance cost, so even if the slower tools are nibbling at our productivity, it's preferable to moving fast and breaking things.
I'm not claiming there's no room for optimization, but 90% of the things that make optimization challenging make the system reliable.
Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)
#368Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)
#369Earlier quoted context omitted.
The point I'm making is that my desktop PC sitting in my office now does have more of everything compared to my 133MHz PC from 1995. Not everything has scaled up at the same pace, sure, but literally every piece of hardware is better now. People talk about difference in resolution and color depth? 640x480x16 isn't that much less than 1920x1080x32. My current resolution has 13 times more data than my 1995 one, and my…
Is it OS and SDK bloat? Where do you think most of the cruft is coming from? Let's say I had a given LOB application written in vb6, c#.net winforms, heck, maybe even WPF. All single-threaded. If I re-wrote the same application (features, UI, still single-threaded) in native Win32, would that improve the latency?
Who knows? My hunch is there's two main factors influencing this. The first is that constraints breed creativity. If you know you only have 133MHz on a single CPU you squeeze as as possible much out of every cycle, on modern CPUs what's a few thousand cycles between friends?
The second is SDK/framework/etc. bloat, which is probably influenced by the first. With excess cycles you don't care if your tools start to bloat.
I think it's primarily an issue of attitude. If you want to write fast software you'll do it, regardless of the circumstances. It all starts with wanting it.
Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)
#370Earlier quoted context omitted.
Also, almost all performance issues come due to features, which nostalgia about the past always ignores. Some specific tasks may have been tangentially faster, but you also had orders of magnitude less features available, and said feature make your overall workflow much faster. None of these people would actually give up on their zsh/autocomplete/fzf/custom git-integrated theme for a few ms better latency.
Let's face it,none of those are compelling reasons for more latency when at the same time the computing power available has ballooned to its current level. Adding auto-complete given processors litterally orders of magnitude faster should have been feasible without getting slower.
Depends, I have fuzzy search decades of command history, that's not a trivial, and it's more intensive than basic reverse search.