How come processors and browsers become faster every year but the internet feels as slow and bloated as ever?
How long can this x% faster continue? There must be some theoretical optimum, how far are we away?
How long can this x% faster continue? There must be some theoretical optimum, how far are we away?
Good thing is, that it's possible to create truly groundbreaking apps using non-conventional techniques, as web becomes faster and richer with new APIs.
For example with Wasm and WebGPU it's possible to create AAA games running in the browser. Someone will do it. It'll be awesome.
I have one example to prove my words. I used iPhone 4S. With iOS 6 I was able to use navigator software which worked very snappy and awesome. Few years later with iOS 9, navigator was very slow, forcing me to buy new phone eventually. With iPhone 8 it returned to blazing fast. But it did not have any new functions. They just started to consume more memory, just because they can. My UX did not change a little bit. I just had to buy new phone with infinitely faster CPU and loads of RAM, just to keep my UX from degrading.
It's also probably another view of the Jevons Paradox: as efficiency of software increases, it gives more way for more complexity and "optimizations" that in the end make the end result as slow as before.
That's a very liberal paraphrasing. Parkinson's law is specifically about the amount of time that it takes to complete work (by humans, e.g. for a project deadline).
If you want to reference something that serves as good commentary about software performance, Wirth's law is right there for the using.
This has been promised since at least the WebGL and asm.js days. It still won't happen, but not mainly for technical reasons, but for business reasons.
...but of course also some technical reasons. Asm.js/WASM and WebGL/WebGPU are fine, but most other web APIs are a mess and the web is a highly unstable platform, APIs are deactivated or deprecated on a whim, APIs change behaviour unpredictably, behaviour differs between browsers, etc etc...
TL;DR: the web needs a proper "DirectX initiative" like what Microsoft did in the late 90's to get Windows gaming off the ground.
Why? We can already play AAA games on our computers. It works very well, much better than anything web-based. Why would anyone put effort into replicating the same thing inside the browser?
This is much more important for indie devs than AAA devs though (the current problems of the web platforms are not really 'AAA specific').
Also, don't forget that PC gaming could very well have died out during the transition from DOS to Windows without Microsoft actively supporting game development on Windows (with the DirectX APIs), without this, AAA gaming could very well be console-exclusive now.
Agreed, however platforms that restrict app distribution also heavily restrict what you can run via the browser (see Ios). So the benefit is minimal.
> a space to try out quirky new ideas
This has nothing to do with web. Look at steam's catalog. Plenty of whacky quirky stuff is available.
> no lengthy download or installation process for instance
Why do you think AAA games will not need downloading assets and logic?
> This is much more important for indie devs than AAA devs though
I agree, but this is a solved problem with Steam. No need to develop your own over the web.
As internet connections get faster it makes sense to stream/prefetch data directly from CDNs as needed instead of downloading everything upfront.
> Look at steam's catalog. Plenty of whacky quirky stuff is available.
Agreed, but that's the exception, not the rule. Look at Apple's app store ecosystem for a counter example where apps and developers are banned on Apple's whim. This couldn't happen on the web.
https://github.com/gpuweb/gpuweb/issues/566
Basically. Rather than doing something better w3c is designing by committee so hard it somehow made worse OpenGL.
A fellow contributor, that had to deal with pain of OpenGL, laughed this shit out of the gate.
And I mean look at it. Who in their right mind looked at that and said, yeah that looks decent.
Basically bunch of stuff listed in that blog are Rust specific uint vs int.
Others are kinda standards problem of undefined behavior being well - undefined. Gamedevs are used to this, but not Rust devs.
I'm reminded of xkcd https://xkcd.com/927/
So rather than relying on previous work, they wrote their own somehow ugliest standard.
- Not knowing you need to have entry point for the shader to be executed.
- kvark's complaint about OpFmod being misnamed are kinda missing the point, % isn't the mod operator but remainder operator (in C/C++)
- https://mobile.twitter.com/TheSpydog/status/1232819839888166... You know it's a pretty bad idea when Unity and Adobe are begging you not to do this.
- I mean what you prefer to write?
GLSL:
int a = 2
for (int i = 0; i < 4; i++) {
a *= 2
}
const a: i32 = 2;
var i : i32 = 0;
loop() {
break if (i >= 4);
a = a * 2;
continuing {
i = i + 1;
}
}I'm also really not sure how you got the first point from what he wrote. He was not saying he was surprised to find "you need to have an entry point" he was saying the restriction made no sense, and that existing tools didn't even take advantage of having more than one entry point due to driver bugs.
The rest of your points are basically just opinions masquerading as something else. In any case I don't actually care how hard WGSL is to write, because I don't have to write it (you can go through a translation layer). What I'm not going to do is pretend that SPIR-V is a great choice for this intermediate layer solely on the basis of what I've heard from other graphics people who haven't actually tried to use it for that purpose--which is exactly what the article is about.
> he was saying the restriction made no sense
So presented with reality of a complex, buggy drivers, his solution is - to ignore it? Wow imagine in UTF-8 people just said, yeah 8bit 0 are ok everywhere and caused hundred of billions of lines of code to be written to deal with null mid UTF8 stream.
> I don't actually care how hard WGSL is to write
Awfully dismissive. Well, ok, you won't have to write it but someone will. And those someone are going to curse whoever wrote that abomination of a spec.
A spec that: - That doesn't respect backwards compatibility - Looks like pure torture to write in - Misunderstands some part like OpRem
I'm not very confident in it to be honest. Looks to me just another overly elaborate moat for browser implementors.
That didn't help the large move to mobile gaming by its primary audience (which I'm guessing was teens).
Towards the end Kongregate became a platform for idle games that pushed users hard towards pay to win. Sucks, but they grew huge off the glory days of ad revenue and I presume they had to do something to keep surviving.
This can change very quickly if there's actually some breakthrough web game, but that hasn't happened so far, and nobody wants to be the first to take the risk.
That's not correct though, the game runs on a Linux box in Google's datacenters (granted, from a business perspective that's nitpicking - but not quite, see below, but it's a massive difference from a technical perspective).
Scaling to large audiences is much more expensive with the game streaming approach though (but we'll never really know because Stadia bombed, just as all other game streaming platforms before).
You want one browser vendor to implement a proprietary API and then have the ramining vendors try to emulate it?
But apart from that, Microsoft was in a unique position to dictate standards to GPU vendors, as draconian as it sounds, this worked much better than Khronos' design-by-committee approach in OpenGL.
Carmack already tried to do it with Quake Live. It did not go far.
You get a shitty distribution model (relying on browser for cache or limited localstorage, or whatever you want it's shitty in the browser and inconsistent, browsers aren't built to handle GB sized assets).
You pay the sandbox tax even in the ideal scenario and there are plenty pathological ones. And even if you aren't performance constrained you're adding battery drain for no benefit.
Then there's the shitty input model and interaction with browser chrome.
And what are the benefits exactly ? Avoiding app stores ? Might benefit the developer but not really a benefit for the consumer.
Slightly off topic but I wonder if WASM and the web can provide a “fixed” virtual platform for games.
A lot of games are heavily platform dependent, when the hardware for those platforms die the games will be nigh unplayable without a huge remastering effort or building an emulator of said platform which may or may not be technically feasible - even on PC we have games breaking as hardware advanced, e.g. Deus Ex had to be patched to work with multi core CPUs if I remembered right.
well, if a company can avoid paying a significant portion of revenue to an app store they might be able to hire better or more developers which might conceivably be a benefit for the consumer.
If indeed the amount of developers employed was inversely correlated with software quality then the best software is that which does not exist. I realize there is a pithy saying that the best code is no code at all but I am not especially fond of such illogical pithiness.
There may be products that it is best they not exist at all, but for products we do want to exist it follows that some number of developers of that product correlates with the quality of its existence.
You don't need such assets to make good games anyway. The obsessions with AAA are unhealthy - many of the best games are not AAA at all, but strictly indie.
I tremendously hate it and it’s not like developers are incapable of building performant software, quite the opposite. But that’s just not where the resources go. The common sentiment (I have heard this directly uttered) is “If the user has 8GB of RAM, why wouldn’t I use it?”.
Case in point: Early last year I created a proof of concept web app that needs to run in the browser and a webview on an old version of Android. I used create-react-app which at the time was the most popular way to... create React apps. This year I updated all the deps and something in the build broke meaning it no longer produces something runnable on the old version of Android we need. There's been an open issue on create-react-app for nearly a year, however it seems Facebook have abadoned that project and everyone has switched to Vite/Rollup now. I spend half a day switching to that which mostly works, except as it doesn't actually bundle, the dev build no longer works on the Android webview - but that's not such a deal breaker. However in the production build treeshaking seems to be completely broken, so the resulting build is a few mb instead of a few hundred kb.
Do you not see that you are the problem in this scenario? Facebook has not abandoned the project and very very few people have switched to Vite/Rollup. You're doing hype driven development.
Now I get this is how a lot of these front end tech are portrayed, and that a lot of these projects could be better in terms of defaults, but what has to be accomplished in front end tech is very difficult. It has to run across so many different browsers, on different operating systems, with different engines across who knows how many devices.
Part of the reason front end development is a mess is because people like you come in, think you don't have to spend any time learning it, and can just put something up because "it's just javascript, it's a toy language". Learn the platform and develop for it. You reached for the biggest hammer you could find when you probably could have used something much smaller and easier to use. You chose the wrong tool, and it's probably because you didn't bother putting in the time to actually figure out what you know and how it would be maintained.
The reason why I choose create-react-app when I first started this project was because it was most popular and recommended way to create a React app. I've hand rolled Webpack and Babel configurations before, and upgrading to the next major version is alwyays a headache, which I wanted to avoid again. Sticking to old versions is equally bad because if someone wants to try something new it's not always possible (two of the biggest frontend apps our company has are stuck on React 15). I figured it's an official project from Facebook, so will be around for a long time and well maintained, but obviously that assumption was wrong for my use case.
The upgrade instructions don't say much [0], but in my case it was a dependency of a dependency of create-react-app which was causing issues. Because of the way create-react-app is built, it isn't usually possible to downgrade or upgrade specific dependencies, or change the configuration for certain parts of it. You just have to go with what they suggest and hope that works for you - which in my case it did not.
In the backend world you will be able to find a LTS version that receives security updates and critical bug fixes for a long time, while in the frontend world your choice is upgrade to a newer version - which often has breaking changes - or stick with the old version - bugs and all.
I gave up with Vite because of the issues I had and went back to create-react-app. I've used it successfully on other - much smaller - projects, but yes for this project it isn't the right tool. Right now I'm trying to make the ejected version do what I need and fix the dependency issues, but if you have any suggestions of what else to try I'm all ears.
[0] https://create-react-app.dev/docs/updating-to-new-releases/
I do have my fingers crossed that Rust+WASM+WGPU will bring about some more efficient products, though.
But I don’t think non-technical users value memory efficiency as much as we like to think sometimes.
> It makes it much easier to develop software
I've never seen compelling evidence that this is the case. Every time this argument is made, it seems to be by a webdev who has no significant experience with building desktop applications. Sure, if you already know webdev, it's easy to build things with webtech. This isn't particularly interesting. I'm much more productive building desktop applications than webapps, but that's because I've spent almost all of my time building desktop applications.
The real question is, given an average developer who has spent around the same amount of time on learning web development and desktop development, and both at a minimum amount of time (say, 100 hours) - which is more productive, and by how much?
I can build a web application and deploy it on the web, on Windows, on Mac OSX, on iOS, on Android, on Linux, immediately. With minimal extra effort, assuming I know what I’m doing.
Correct me if I’m wrong (it’s possible), but I don’t think that’s at all possible with native libraries, or even cross-platform frameworks like Qt.
It also means companies don’t have to hire multiple product teams. They can hire one team.
So even if native development is 10-20% more productive (I’d disagree, but for arguments sake), it’d still fall short.
Webtech might score low on the CPU efficiency scale, but it scores very high when it comes product timelines, headcount, payroll and (arguably) ease-of-hiring.
This is why I think webtech almost always makes more business sense. At least for your typical SaaS product.
This is why I’m excited for WASM. We might finally have the tooling for truly cross-platform development without sacrificing efficiency/low level control.
1) Chrome in Android has recently begun to hang when trying to go back to a previous page. It's gotten so bad that I end up clicking multiple times, which all register in rapid succession. If I click more times than the history depth for the tab (say 3 or 4), I end up back on the home screen and a lost tab with lost (or at least not conveniently recoverable) history.
2) AMP. When Google began pushing AMP my objections were mostly based on principle; performance was mostly a wash for me. Now the AMP viewer is so slow and so crash prone that I'm conflicted. On the one hand, I'm glad to see that AMP is clearly failing. On the other hand, Android and Chrome still strongly favor AMP, and I'm too lazy to wrestle with Google over default settings, so when I don't have the presence of mind to explicitly open a web site (e.g. when using Google News) I'm left to suffer the poor performance and bugginess in addition to other intentional AMP headaches--lack of copy+paste, less scrolling and zooming control, etc.
Not quite the same thing, but related, technologies like QUIC are really only beneficial in the context of a web ecosystem built by Google. QUIC shines on websites pulling in many resources from disparate hosts, which in most cases is a situation created by advertising and analytics services. IOW, these days much of the benefits of Google's work simply pays down the debts Google itself created or advocated. And while Google still stands out for the amount of labor it invests in open source security and performance, it's just a matter of time before we pass break even into negative return territory. That happened long ago with Google Search itself; Google Search results are as slow, irrelevant, and obscured by obnoxious and misleading advertising as the competitors it originally, rapidly displaced. Heck, when Google began those investments (Android, Chrome, OS security, etc) they were crystal clear why they were making them--to nurture and grow an ecosystem into which they could grow their advertising business, same as their rationale for making a snappy search service and a non-intrusive advertising network. There's a limit to how well they can improve that ecosystem, but the limit for exploiting that ecosystem can easily result into a situation far worse than the one Google originally saved us all from.
Consider why rendering work is even relevant in 2021. It's not for the benefit of services like Netflix or YouTube, which already enjoy low-power hardware acceleration, and arguably not for games or similar interactive content. It's so they can continue shifting their advertising ecosystem from minimalistic text-focused display boxes to animations and videos peppered up, down, over, and under content views. They can't do that if advertising-laden web pages drain your battery in 15 minutes, as notorious Flash-based ads once did. Steve Jobs' famously removed Flash from mobile; Google, for obvious reasons, is taking the alternative path.
I get annoyed with how slow Chrome is, so I switch Firefox. After a while the Firefox profile gets bloated and I get annoyed and switch back to Chrome with a clean profile and it feels really quick again. Ad infinitum.
That's on a Galaxy S4, mind you.
Dillo is blazing fast on desktop, but doesn't support https very well. It also doesn't support JavaScript, which isn't a big deal to me.
That system did run Windows 3.0, and later on 3.1 & Windows 95, but for a lot of tasks I would just use MSDOS and be done with that. Even running character mode Linux with pre 1.0 kernel in multiuser mode was fairly snappy in those days.
The first generation unibody macbook pros running OSX felt fairly fast and snappy back in the day, but even that was no match to the peak MSDOS speed. And I suppose that snappiness was felt mostly because Windows XP while fast, was not the snappiest OS out there.
In 2021 with every component seemingly 100x faster than those systems, with a 8 core i9 CPU on my MBP 16, I dont see any environment being that fast. I really miss peak MSDOS experience from the days of Windows 3.0 era.
MacBooks aren't cheap. For the average person they are a significant expense. So the lifetime of support should reflect that.
What's the point of new hardware if the new software that's written for it makes it just as slow (or in this case: much slower) than the old hardware?
I am still pissed off that my 2012 Macbook Air is no longer receiving OS updates - compare that to Microsoft that allows me to run windows on basically any PC
“What Intel giveth, Microsoft taketh away”
And also many websites include more tracking, for example Google search results used to directly send you to the result page. Now they first send you to Google so that they know you clicked but it also adds noticeable latency.
Now in 2021, most popular websites use CDNs and have servers based out datacentres closer to India and the page load speed and latency has gone down significantly for us.
But page bloat is a different matter, I still remember spending the greater part of a day (or maybe more0 downloading the MSIE 2.0 installer on a 1200bps dial up modem. Today page sizes > 1mb are common even on mobile sites.
https://nanoreview.net/en/cpu-compare/apple-m1-vs-amd-ryzen-...
Compare Zen 3 to M1... M1 is a generation ahead in lithography and enjoys an appreciable thermal/efficiency advantage resultingly. Zen 3 and M1 have neck-and-neck single core performance on many tasks. Yet Zen 3 can offer many more cores and make up for its efficiency in raw thermal envelope availability.
Then also the expectation from older and more inexpensive devices. If one gets used to M1-level performance, a $200 CPU from 4 years ago starts to look quite slow; e.g., the Ryzen 5 1600:
https://nanoreview.net/en/cpu-compare/apple-m1-vs-amd-ryzen-...
Once we start to look at the truly power constrained, say a mainstream phone from a few years ago; let's say the iPhone 8/X since it's one of the best selling in recent history. Then you're at about 50% of the single threaded performance AND working with fewer cores.
https://en.wikipedia.org/wiki/List_of_best-selling_mobile_ph...
https://www.cpu-monkey.com/en/compare_cpu-apple_a11_bionic-1...
There is another large factor at play in the past 20 years in particular though: that is the increasing predominance of "Python-like" languages. I mean that in the sense that more of the code we interact with on a daily basis is written at a very high level than 20 years ago. Python in particular is just about the least efficient of all the most widely deployed languages.
Ranking Programming Languages by Energy Efficiency: https://haslab.github.io/SAFER/scp21.pdf
2021 Top Languages: https://spectrum.ieee.org/top-programming-languages/
(But they get more power efficient and quieter, this is true.)