Just Released Galaxy S9 Slower Than iPhone X/8 | Hacker News Reader

Just Released Galaxy S9 Slower Than iPhone X/8

thenextweb.com

9 pointsnkjoep16 comments

Even better, it loses to iPhone 7. Apple silicon is really far ahead right now.

And Apple software is really, really far behind. You can find videos going back many years on YouTube of previous generation midtier Android phones besting latest generation top of the line iPhones in day-to-day tasks like launching communication, browsing, and social apps. Somehow, Apple forgot to optimize for what people actually use their devices for.

Years ago: https://youtu.be/hPhkPXVxISY

Months ago: https://youtu.be/YH3uVWFoHe0

How is it that their software and OS is unable to use that processing power? Or does the A11 get so hot that it needs to be substantially throttled? The countless speed tests on YouTube showing the iPhone X losing to Android phones with an old Snapdragon 835 are amusing to say the least.

However, this Galaxy S9+ vs iPhone X video review apparently tells a completely different story:

https://www.youtube.com/watch?v=UY4a0IPXotA

While the S9+ seemingly handles everything and anything you throw at it the X has some obvious difficulties every now and then.

PS: I (still) have a (ancient) iPhone 4 right now. No fanboyism here.

This is for the Exynos version which is slower than the USA/China version which uses Snapdragon 845.

As a rule, performance of flagship Android phones lags iPhone by 2 years or so. Been that way as long as I can remember. Worse, floating point perf lags by about a factor of 3. I don’t know why Qualcomm and Samsung keep doing this to themselves. It’s not like they can’t design decent chips. They just choose not to. The situation is further exacerbated by Android being a disorganized, sloppily put together pile of excrement.

That's your opinion.

I personally wouldn't touch an iphone with a ten-foot pole. I don't like Apple's business practices, and I don't like their hardware (no headphone socket/no SD card/smaller screen than I'd like).

Android isn't perfect, but I find it to be much more usable and logical in the way it works. I have done some Android programming so maybe I just understand it better than most, but my partner and my mother also seem to be able to use it fine. I certainly wouldn't describe it as a "sloppily put together pile of excrement". I am able to work around Android's deficiencies, something I can't do when locked in the Apple jail.

FWIW, when I think of a "sloppily put together pile of excrement", I think of itunes.

Try to use their camera2 api to see what I mean about sloppily put together. I’m with you on iTunes. Thankfully I haven’t had to use it in years.

An enduser doesn't need to know about the camera2 api to take a photo.

I was mistaken, I thought you were discussing usability for endusers, not about programming issues.

You mean the same camera2 API that's used by the Google Pixel 2 - the world's best smartphone camera?

Let me assure you, this was possible in spite of, not thanks to this API. Words fail to describe how horrible and unusable it is.

When looking at the API, you have to take into account limitations the designers had. Specifically, the API is part of the android layer that Google writes and OEM's can customize. It must, however, support any underlying camera HAL and associated hardware. The software for that is typically written by SoC vendors, and therefore the camera2 API needs to work with existing HAL layers without modification.

Camera API's also need to be performant. Specifically, converting the data from one form to another, compressing or decompressing it, adjusting colorspaces, rotating it, or copying it from one memory to another typically isn't possible to do as part of the abstraction.

Simple things like rotating a 240fps video to be the right way up in real-time really aren't doable, which means those details have to be passed on to the application if the camera hardware is mounted the other way up.

That means the API itself needs to get the application to handle those details if it wants to offer performance.

All those possible hardware details which the API can't hide for performance reasons lead to a huge and complex API. If you want a simple API, you're free to build one on top (and some exist), but beware - performance will be atrocious on some hardware.

Excuses, excuses. Meanwhile iOS API for the same thing requires 1/10th the amount of code, is easy to use, and has great documentation.

Except they can modify the hardware and HAL layers... Google cannot.

Funny isn't it how an Android phone with an old Snapdragon 835 from last year can so easily beat an iPhone X.

https://www.youtube.com/watch?v=uL99tRQR9W0

The "sloppily put together pile of excrement" iPhone X can't even keep apps in memory as it loses to an Android phone from last year. If a Note 8 can make the iPhone X look that bad just think what this year's S9 will do.

Both apple and Google have people working on optimizing this type of speed test. You wouldn't believe how much pressure the Unity game engine Devs were put under to make loading fast and memory use low. A lot of work was put into letting textures be readonly, pageable and backed by flash when the app is in the background, which dramatically reduces the dirty set size of apps and lets you run many in the background at once.

Therefore, I would suggest it's best to use other kinds of real world tests, like for example completing a specific set of tasks, or webpage loading tests, which aren't yet over optimized.

Reply on news.ycombinator.com