2) Your phone is not nearly as powerful as your laptop despite similar specifications of the CPU speeds. Pretty much everything other than the base CPU clock rate is much, much slower. In addition, your phone CPU down-clocks itself due to thermal limitations where your laptop has a fan and much better heat dissipation capabilities. As a result, it is almost never running at the maximum rated clock speed.
On a YouTube talk I watched (skewering web site speeds and JavaScript overloads), the speaker's iPhone, with CPU specs similar to his laptop, was 25 times slower than his laptop when rendering a (JavaScript heavy) benchmark page.
Where he talks about benchmarked speed vs. marketing numbers: https://youtu.be/4bZvq3nodf4?t=676
Sometimes we stop just a bit too soon. I’ve found a great rule of thumb is that once you’re code complete on a module, put in an extra 10% of work with the profiler to try to improve performance. Keep doing 10% spurts until the performance improvement of the last spurt is less than 5x.
There’s almost always low hanging fruit which will return at least 10x. Sometimes you find multiple places where you get 10x and your code ends up more than 100x faster.
And at that point all your unit tests are written and green so the refactoring is pretty quick. Right? ;-)
It's often the case that optimizing a special case 10 times increases throughput, but makes the user experience worse (because it starts stuttering), makes the code ugly, and allows for timing attacks. So, in many contexts it's actually bad idea.
Half the work in optimization is measuring the correct thing.
I beg to differ.
My Droid Turbo is powered by a 2.7 Ghz quad-core CPU, yet often is incredibly slow. If I want to open Waze and enter and address to navigate to, it's often 10-15 seconds from the time I tap the Waze icon on the launcher until the apps is loaded and the on-screen keyboard has presented itself for typing.
There are significant stutters when I'm trying to scroll while a web page is loading.
Fallout Shelter takes nearly an entire minute to load.
Sometimes, plugging in a USB charger causes the phone to basically become a brick for half a minute or more, as if there are tons of apps deferring processing until I'm on external power.
Overall, it often doesn't feel any more responsive than my original Droid back in 2010, which was only a 550 Mhz single core.
This came up on another thread here from a blog/article titled "software disenfranchisement". I mentioned that I think a lot of it is an unhealthy obsession with writing re-usable code that results in abstractions on top of abstractions piled onto more abstractions to the point where we get the infamous FizzBuzz Enterprise Edition [0] that I'm sure nearly everyone at HN has seen. We also have a problem of people statically linking massive libraries when they only need a small fraction of its code.
> user-hostile decisions that prioritize ads
Definitely a problem in mobile web browsing. Ridiculous that on a data-limited connection, ad networks still try to push video ads or ridiculous JavaScript code.
> But clock rate is truly meaningless as a performance measure when the underlying architecures are different...
Definitely true. ARM gets a lot less done per clock tick than x86. But I imagine a lot of the performance differences are done on purpose as a compromise to reduce power consumption, since ARM is so big on mobile platforms. This is entirely speculation on my part, though.
[0] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Phones, on the other hand, are highly specialized - PC's are general purpose. Trade off is often power requirements and performance.
My 8 core 16 thread Ryzen Gaming PC smokes anything my phone can do and i guess if i really wanted to compare i could do a taskper watt calculation and see how they compare.
When i use my phone like a computer, its power draw increases and i get just a couple hours of battery use. play fortnite on your phone and it goes dead quick.
Phones on the other hand are rarely plugged in, and consumers clearly demand more battery life. This has led to resources being poured into cell phone battery capacity and into efficiencies in power usage.
I haven't done a ton of side-by-side comparisons, but it does feel like ARM runs more efficiently per watt.
Phone SoCs specifically address that by having 2+ CPUs of varied power, and having the high-power CPUs completely shut down and powered off when idle.
Same applies to GPU cores that eat significant power when idle, and a lot of power when fully loaded. A PC with a 600W PSU likely features a large GPU that can consume e.g. 300W under full load, doing 60fps photorealistic rendering, or training a neural network. Phones just don't have this kind of hardware (they have much smaller ans less complex GPUs), and, again, manage to keep them powered down when not in use.
Again, a PC drawing 50W or less while doing light office work is a pretty normal thing.
Power consumption is between square and m^n to inter-core bandwidth and count.
So, a high-end smartphone CPU might do 1/5th of the throughput of a desktop CPU using 1/25th of the power.
Just guessing here, by pulling apart what little is in there:
* Total power usage has a big fixed parts, e.g. screen power usage going up linear with brightness and screen size. Or RAM power usage goes up linearly per bit just to keep the memory intact. So Let's assume OP talks about only the 'clocked' components, like CPUs and busses.
* I did hear for single core CPUs how the power usage arose with the square of the CPU speed, unless offset by die shrinking or technological advances. This was one of nature's walls hit by the Pentium IV. Can't find a good reference atm, but here http://www.tomshardware.co.uk/answers/id-3025075/higher-cloc... is a page with the first graph looking square-ish being what happens with power usage when clock goes up on the same machine.
* And throughput is linear with clock speed, if nothing else changes. If you double your clock, you double your throughput just by moving more data over the same bus. So the third line of OP is consistent with this: 1/5 of the throughput is reachable with 1/5th of the clock, thus 1/25 of the power.
* First line might compare 2 ways to raise the throughput: Either rise the speed of 1 core or add more cores. When you rise the speed of 1 core, power goes with the square of this rise. When you add more cores, power goes linear with these cores, assuming your interconnect is free.
* Second line 'between square and m^n' needs some interpreting. It might make sense when for a square n=2, and m measures frequency/throughput/core count/... . I assume he says the real relation might be power usage = throughput^2.3 for example
* When you have m cores, and each is interconnected to its m-1 brothers, you have m*(m-1) interconnect elements using power. This is again a square law. You can get around this by not connecting everything to everything, but this will cost you in data throughput - There will be bottlenecks.
Thats what i can make from it.
https://physics.stackexchange.com/questions/34766/how-does-p...
First answer says P goes linear with f, based on theory.
Second answer goes for cubic or worse based on some deep papers, but a comment says this is dated.
Third answer has a graph from real-world measurements which is clearly worse than linear, and a comment saying there is an exponential part somewhere there too, but it is swamped by linear factors.
WIkipedia, by the way, goes for linear - https://en.wikipedia.org/wiki/CPU_power_dissipation#Sources
I think the most realistic answer I can give is: It is complicated, and OP is a very good nerd sniper ;-)
If you actually use battery intensive apps like google maps' you will quickly realize your battery isn't going to last very long.
There is simply no comparison to make when we are talking raw compute power. If there were, the DC market would be dominated by x86 processors with stupidly low power consumption. The cost savings from the smaller power/heat footprint would be absurd.
Old school mainframe power suplies are probably even less efficient per what.