5 ms·
On 2), using the iPad Pro puts me in the opposite camp, where sheer performance is better from my perception. The limitations come more from what I can do that
by hrktb 6y ago
On 2), using the iPad Pro puts me in the opposite camp, where sheer performance is better from my perception. The limitations come more from what I can do that how good/fast/responsive it is done.
I get there is more to it that just an ARM vs x86 straight comparison, but even my 2019 MBP feels less smooth when it comes to simple and comparable tasks like browsing sites while watching videos.
- andai 6y agoThese days I will often use my phone instead of my desktop because it's less laggy. Admittedly my computer is a few years old, but so is my phone!
- wayneftw 6y agoWhat activity could possibly be less laggy on your phone? I can't stand using my iPhone or my iPad for anything other than very basic features since they're so slow and limited compared to how quickly I can get things done on one of my real computers. Selecting text or placing the cursor on a phone is an exercise in frustration. Browsing the web too - I have to contend with every other website treating my phone like a 2nd class citizen and some sites like Reddit or Twitch try so hard to force you to use their app. On Google I have to either use desktop mode and zoom in after each search or I have to put up with shitty AMP results. I basically associate ARM with shitty locked-down operating systems that don't have my best interests in mind.
- roamerz 6y agoYou had me with you until the last paragraph. I appreciate my ARM device. In my case an iphone. Out of all if the other ‘brands’ Apple comparatively has my best interests (privacy and security) in mind. With some of the mentioned trade-offs of course.
- grawprog 6y agoYour best interests are not necessarily everyone's best interests, security at the expense of freedom is not mine or many other people's best interest.
- api 6y agoSecurity/privacy and freedom are at odds these days. Freedom means the freedom to install malware and spyware and the freedom for said malware and spyware to run wild on the device. Android is more free than iOS, which means Android apps are much more free to spy on me. If you are technical enough and conscientious enough to avoid this problem that's great, but that's not the majority of the market. For most users freedom means malware and highly invasive surveillance. The Internet and the computing ecosystem decades ago was comparatively open and free. Then the barbarians came in the form of surveillance capitalism and industrialized malware operations. Now the fields are salted, the smaller settlements are burned to cinders, and everyone is cowering behind the high city walls of various walled gardens.
- saagarjha 6y ago> Security/privacy and freedom are at odds these days. They don’t have to be; it’s just that this is the option we have right now.
- entropicdrifter 6y agoMeanwhile, Linux phones are starting to become a thing, even if they're just a group of survivors trying to tame and cultivate their own desert island
- buran77 6y agoMuch of the security afforded by systems without too much market share is that they are not seen as a juicy enough target. But any juicy target in the hands of a regular user (not an enthusiast, not an expert sysadmin) will be exploited. The more flexibility the user has, the bigger the chances they will pick convenience over security making the system even easier to exploit. There's no system that will make everyone happy so the interests of the many for security outweighed he interests of the few for tinkerability.
- oarsinsync 6y ago> What activity could possibly be less laggy on your phone? Photos on my iPhone SE (2016) or 9.7" iPad Pro (2016) is significantly more performant than Photos on either of my MBPs (13" & 15", 2015). Like massively so, to the point that I absolutely loathe having to use my Mac whenever I need to do anything with a photo or video.
- api 6y agoThat's probably because photos are an incredibly common task on phones and so the software has gotten a huge amount of optimization attention. I don't think it's a hardware issue. Phone UIs in general get more love just because with that tiny screen and given the normal causal use cases users are far less tolerant of slow or poorly designed UIs on phones. The squeaky wheel gets the oil, and on mobile any UI issue is instant death. On desktop it's just an annoyance.
- oarsinsync 6y agoThe point was to give an example that desktop/laptop computers do not always result in better performance than phones. The GP didn't seem to believe it was possible that a phone could be "less laggy". In line with your own remarks, there are a number of common use cases that have been optimised on phones in a way that they never were on desktop, resulting in a superior user experience on the phone vs the desktop.
- zozbot234 6y ago> Selecting text or placing the cursor on a phone is an exercise in frustration. That's just a difference in UI - a small phone touchscreen is simply not a very effective input device compared to even a plain touchpad using the exact same area. (To the point where I think all touchscreen-only devices should support "touchpad mode" with a pointer out of the box. VNC/RDP implementations on mobile devices have been doing this for ages, so it's quite physically achievable.)
- gruez 6y ago> On 2), using the iPad Pro puts me in the opposite camp, where sheer performance is better from my perception. The limitations come more from what I can do that how good/fast/responsive it is done. How much of that is because it's using a 120hz display, vs 60hz on most computers?
- packetlost 6y agoIn the context of this argument, does it matter? If you're doing the same tasks (ie. web browsing, as mentioned) and one is noticeably better or as good, the conclusion would be the ARM processor in the iPad Pro is at least as good as the processor in the 2017 Macbook at the task in question.
- regularfry 6y agoIf it's just the refresh rate, that's nothing to do with the CPU (or, at least, nothing to do with the parts of the CPU that are meaningfully different between x86_64 and arm64).
- packetlost 6y agoMy point is that even if the primary reason it appears better to the user is the high refresh rate, then the CPU must be no worse than the other, because that would cause a degradation in CPU intensive tasks such as web browsing.
- regularfry 6y agoIt depends how big the effect is. Human perception is abysmal at judging performance. Particularly with web browsing, if you've got snappy compositing and the UI is otherwise slick, a slow browser performance will get blamed on the site, not the CPU.
- mekkkkkk 6y agoThe argument wasn't that they were equal, but that the ARM chip appeared _more_ performant than the x64 one. It's a legit point that refresh rate could make it appear so even if the actual performance is roughly the same.
- pjc50 6y agoSince the early days of Quicktime Apple have been quite good at keeping multitasking feeling more realtime on desktop systems. So far as I can tell, Apple's advantage is a vertical integration one, enabling them to choose their own goalposts. Those seem to include "run Javascript as fast as possible", which involves using an Apple-tuned JIT compiler on an Apple-tuned ARM core. I'm not sure whether they're directly responsible for the ARM Javascript instruction ( https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip... ), but you can be sure they're going to use it where appropriate. Combine a thousand similar bits of full stack corner shaving, and you get an advantage. Jeff Atwood has Opinions about this, e.g. https://blog.codinghorror.com/the-tablet-turning-point/ https://blog.codinghorror.com/the-tablet-turning-point/ The virus scanners tend to give standard PCs a massive disadvantage in percieved performance against locked-down tablets, too.
- saagarjha 6y agoInterestingly, Jeff Atwood was the one speculating that A12's Speedometer performance was due to JavaScript instructions: https://twitter.com/codinghorror/status/1049082262854094848 https://twitter.com/codinghorror/status/1049082262854094848. Turns out, no, it wasn't–it's one instruction that doesn't determine the performance of the test, and JavaScriptCore wasn't even using it. Most of the performance just comes from the JIT being really good and the chip's raw performance being good.