Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fast machines, slow machines (2023)

jmmv.dev

Post reply on HN
Print view View original

21–30 of 72 posts

Re: Fast machines, slow machines (2023)

#21

Post by nottorp »

maccard wrote: post #7

The author mentions rewriting core applications in C# on windows but I don’t think this is the problem. Write a simple hello world app in c#, compile it and see how long it takes to run vs a rust app or a python script - it’s almost native. Unity is locked to a horrifically ancient version of mono and still manages to do a lot of work in a small period of time. (If we start talking JavaScript or python on the other h…

> Unity is locked to a horrifically ancient version of mono and still manages to do a lot of work in a small period of time

Unity is the great battery killer!

The last example I remember is that I could play the first xcom remake (which had a native mac version) on battery for 3-4 hours, while I was lucky to get 2 hours for $random_unity_based_indie with less graphics.

Re: Fast machines, slow machines (2023)

#22

Post by kreco »

drob518 wrote: post #12

Startup time has always been a bit of a sketchy metric as modern OSs and languages do a lot of processing on application launch. Some scan for viruses. On Macs you have checks for x86 vs Apple silicon and loading of Rosetta if required. Managed runtime environments have various JITs that get invoked. And apps are now huge webs of dependencies, so lots of dynamically linked code being loaded. A better metric is their…

Why not both?

The applications are launched at startup time because they have runtime startup slowness. The applications have startup slowness because of the JIT runtime/deps/.dll.

At the end of the day, end users pay for the cost of developer convenience (JIT and deps most of the time, even thought there are some case where dynamic linking is alright) because they don't do native apps.

Offloading everything at startup is a symptom IMO.

Replying to your specific point about virus scans. For some (naive) reason, I expect them to run a single time against a binary app that is never changed. So in theory it shouldn't even be a problem, but the reality says otherwise.

Re: Fast machines, slow machines (2023)

#23

Post by jebarker »

coolcase wrote: post #3

Are mobile devices slow/unresponsive. I haven't experienced that unless I realllllly cheap out. Or after 4 years of OS updates on Apple devices for some reason. Androids seem OK in this regard.

I have a top end Pixel phone running stock Android and encounter latency all the time. All first start time is usually a couple of seconds. Switching back to an open app is fast in many cases but some still have to do a refresh (which I suspect involves communication to servers, although that's still not much of an excuse).

Re: Fast machines, slow machines (2023)

#24

Post by nottorp »

maccard wrote: post #9
coolcase wrote: post #3

Are mobile devices slow/unresponsive. I haven't experienced that unless I realllllly cheap out. Or after 4 years of OS updates on Apple devices for some reason. Androids seem OK in this regard.

I switched from android back to iOS last year. There seems to be some sort of inherent latency in either android or Samsung’s UI that causes the UI thread to lag behind your inputs by a noticeable amount, and for the UI thread to block app actions in many cases. Things like summoning a keyboard causing my 120hz galaxy phone to drop to sub 10fps playing the intro animation for GBoard were just rampant. All non existen…

But but ... Samsung has bigger numbers in the spec sheet! It must be faster!

Re: Fast machines, slow machines (2023)

#26

Post by jebarker »

So is there any hope for improvement?

Personally I've decided to just vote with my feet and avoid using poor performing software as much as possibl, but that's frequently impractical or not worth the cost of missing out. I also doubt this will change the behaviors of companies as we see with, for example, TV advertising that they give no shits about degrading the consumer experience over the long term.

There doesn't seem much hope on the technical side either as software complexity is only increasing.aybe longer term AI has a role to play in auto-optimization?

Re: Fast machines, slow machines (2023)

#27

Post by smilliken »

yobbo wrote: post #18

I suspect (in a common pattern) the main thing that blocks making performance a priority is that it equates to reordering various ranks among developers and product managers. When performance supersedes "more features", developers are gatekeepers and manager initiatives can be re-examined. The "solution" is to make performance a non-priority and paint complainers as stale and out-of-fashion.

Or you can have technical managers that understand what they are managing.

Re: Fast machines, slow machines (2023)

#28

Post by RetroTechie »

maeln wrote: post #11

More than CPU speed, I think the increase in storage and RAM is to blame for the slow decay in latency. When you have only a few Kb/Mb of RAM and storage, you can't really afford to add much more to the software than what is the core feature. Your binary need to be small, which lead to faster loading in RAM, and do less, which means less things to run before the actual program. When size is not an issue, it's harder…

It's also complexity - added more than necessary, and @ a faster pace than hardware can keep up with.

Take font rendering: in early machines, fonts were small bitmaps (often 8x8 pixels, 1 bit/pixel), hardcoded in ROM. As screen resolutions grew (and varied between devices), OSes stored fonts in different sizes. Later: scalable fonts, chosen from a selection of styles / font families, rendered to sub-pixel accuracy, sub-pixel configuration adjustable to match hw construction of the display panel.

Yeah this is very flexible & can produce good looking fonts (if set up correctly). Which scale nicely when zooming in or out.

But it also makes rendering each single character a lot more complex. And thus eats a lot more cpu, RAM & storage than 8x8 fixed size, 1bpp font.

Or the must-insert-network-request-everywhere bs. No, I don't need search engine to start searching & provide suggestions after I've typed 1 character & didn't hit "search" yet.

There are many examples like the above, I won't elaborate.

Some of that complexity is necessary. Some of it isn't, but lightweight & very useful. But much of it is just a pile of unneeded crap of dubious usefulness (if any).

Imho, software development really should return to 1st principles. Start with a minimum viable product, that only has the absolute necessary functionality relevant to end-users. Don't even bother to include anything other than the absolute minimum. Optimise the heck out of that, and presto: v1.0 is done. Go from there.

Re: Fast machines, slow machines (2023)

#29

Post by TacticalCoder »

graemep wrote: post #4
sshine wrote: post #2

Back then, programmers had to care about performance. The field of programming was less accessible, so the average skills to reach the barrier to entry were higher. So people were, on average, better programmers. The commercial incentives of today to reach market with something half-assed and then never fix it don’t help. In 2002 I ran OpenBSD on my laptop (thus sacrificing wifi). The memory footprint of running X11,…

Browsers are the big problem. Security and compatibility push upgrades to the latest, very heavy, ones.

[dead]

Re: Fast machines, slow machines (2023)

#30

Post by RetroTechie »

yobbo wrote: post #18

I suspect (in a common pattern) the main thing that blocks making performance a priority is that it equates to reordering various ranks among developers and product managers. When performance supersedes "more features", developers are gatekeepers and manager initiatives can be re-examined. The "solution" is to make performance a non-priority and paint complainers as stale and out-of-fashion.

Probably more common is that software isn't developed with end-users as #1 priority; it's developed to advance business goals.

Those 2 goals align about as often as planets in our solar system.

To some degree this is true for open source software as well. Developers may choose to work on features they find interesting (or projects done in a language they feel comfortable with), vs. looking at user experience first. Never mind that optimizing UX is hard (& fuzzy) as it is.

Or all the work done on libre software to cater to various corporate interests. As opposed to power users fixing & improving things for their needs.

Post reply on HN