"You seem to believe that he cannot possibly be an expert."
Bringing up writing a compiler in relation to SoC design is, in itself, absurd. It undermines the expert claim to begin with. Waving one's hands at "industry mumbo jumbo" (even ARM reference architectures) and alluding to your own claims of knowledge is...incredibly ignorant. It is so far below what HN aspires to be it boggles.
It is what they said that discounts the mere possibility that they have even a basic layman knowledge of the topic, much less are an expert.
"I am embarrassed for you because you have seemed to be very mean and dismissive."
Did you read what DannyBee was saying at all? In response to empirically proven, well backed statements they disagreed, did the knowing wink and patronizing pat on the back, and pretended to have more knowledge based upon a growing volume of claims (first "write compilers", then "toolchain", then "toolchain bringup", none of which have anything to do with SoC-targeted schedulers). I didn't fire the first shot in being "mean and dismissive", and considering how profoundly ignorant this whole discussion is I was being as kind as possible.
It's actually interesting: You have no idea what my qualifications are, or my interest in this topic. Nor do I expect anyone, which is exactly why I cite actual data and information, not just my wink-wink/trust me/"don't believe those SoC fatcats" knowledge.
Run fast and go to sleep has always been the primary power policy.
A sleeping core is obviously the most efficient core, however you have said nothing to discount what I said. Putting a core to sleep is a very costly activity, which is exactly why it happens at the millisecond scale.
Before that happens, the core will likely have been frequency scaled to more appropriately fit the window's loading. I mean, we know this is the case right now, and that "run fast and go to sleep" is not the primary policy. It's "run as fast as appropriate for the workload to fill a quantum, and sleep when there is no workload". There are many if not most workloads that are externally bound, or event triggered enough that sleep is completely out of the question and running faster does nothing.
Your words have been used (out of context and inappropriately) to bolster DannyBee when they represent, literally, all that is wrong with Hacker News.
This thread should embarrass you. Christ, I'm embarrassed for you.
I linked multiple real world demonstrations (both the technical data, and actual observations of these cores in practice) of how big little is used for power consumption, including specific details of the core power profiles. You still allude to your great, clearly laughable, expertise and actually continue arguing this. Remarkable.
You are a Hacker News "Expert" and a bore. You are far, far out of your depth, and you should stop responding to topics where your knowledge is hilariously wrong.
you literally have no idea what you are talking about when it comes to CPU sleeping
He said that cores slept as much as "every 50ms". 50ms is an enormous period of time, and is a colossally granular mechanism of power reduction. They didn't discount what I said at all (in fact, talking about the millisecond scale when discussing a costly CPU activity is pretty bizarre to begin with), though it is unsurprising that you try to hang on that.
Not to mention that their comment is simply dated and wrong now regardless.
anything other than self-serving industry press releases to back up your claims.
Comical. And yet you'll wave your hand at "battery life" based upon utterly nothing. Hey guys - ARM, Samsung, Qualcomm --- disregard them, and disregard actual observations of how these SoCs operate in the field on varying demand workloads -- because this guy knows how compilers are written and he does little winky faces.
Save the world from your ignorance. The mere fact that you continually reference your great compiler writer knowledge in relation to core design is, honestly, embarrassing.
The amount of CPU time you should be spending on these tasks is really low.
Which is exactly the point. They are not CPU intensive, but the CPU is constantly doing a multitude of little things, whether simply moving memory around from the GPU to storage, sending the render buffers for the 60fps display, etc. Another comment mentioned, rightly, that cores are put to sleep in they don't have anything to do in a quantum. A quantum is an enormously huge period of time, and is a macro power management technique, and is the last bastion behind idle frequency scaling, and big.little.
Truthfully, for most A53 cores, this is true only in the dreams of the chip designers.
You have zero expertise to be saying this. I mean, here's how Samsung actually does it on a big/little setup-
They favor the little cores, unless the process actually saturates the core at which point it is elevated to a big core, because the power profile for low demand tasks is far better for the small cores.
I'm going to favor the industry's interpretation of this a bit more than your anecdotal, occasional compiler-writer knowledge.
what do you expect the A57's to be doing in this world?
You don't want A53's "handling the majority of the workload".
Yes. You do. If I'm casually browsing non-intensive web pages, e-reading, or watching a Netflix movie, or even encoding a video, the background is doing IO rate limited system updates and basic data logging, etc, the vast majority of the time the CPU demands are very low, but frequent enough that putting a CPU to sleep is completely out of the question.
An A53 has a much lower ceiling, but a much better middle tier power usage level, than the A57. Yes, if you want to run a benchmark the A53 is not a good bet (and is generally worse in a workload power usage), but it is a very good bet for most real world usage.
The 808 is also a big little architecture, with two A57 cores and four A53 cores. The A53 cores will likely carry the vast majority of every day use, and redouble the battery savings.
As a Nexus 5 user I'm pleased with most of the changes and non-changes. 2GB is fine for a smartphone, and an image sensor with more than double the light capture area per pixel is brilliant, and if it delivers the better photographs will be worth it right there. Losing OIS...I don't think that's a downgrade as OIS was always suspect to begin with (not least because OIS only helps for lateral movements. It does nothing for rotational movements, and of course make subjects stand still. It yielded a tonne of unusable photos).
The only thing I'm really displeased about is the removal of wireless charging. That was a really nice feature.
Between the Snapdragon 810 and 808, the only real items of concern is that the 808 does not have h265 hardware encoding (the 810 does), and its image processing DSP is 12-bit per pixel rather than the 14-bpp of the 810.
I pay $30 for 6GB of LTE data per month (Rogers, via a promotional plan that they've offered countless times). And I generally use about 200MB in an average month as I'm virtually always around WiFi of some sort. Which is exactly what Google envisions, with most of their cloud solutions defaulting to only operating over WiFi.
SD storage has always been a mess on Android because it was originally added just as an easy way to port music and movies over. It was essentially supposed to be read-only memory. Then of course apps and users started using it and the ugly, messy history is notorious.
Updates to Xcode added what Android's tools have had for years, which is the notion of generating multiple binaries for different devices/profiles. Xcode then signs those independent sections and packages them together in an archive, while Google has you send them up separately, each signed separately.
Apple sort of presented it like the App Store is picking and choosing, but it's the enhancements to Xcode that actually enable the functionality. Google could add some tooling improvements to make it slightly easier, but really they've already done all of the hard parts.
Expansion files were a hack, and remain a hack. They are necessary for large games obviously, but really 100MB encompasses the enormous bulk of apps with ease. It would be ideal if Google simply abolished expansion files and folded the sizing into normal APKs.
Google announced smart updates and then enabled it (they had already been using this for Nexus system updates). There is absolutely nothing any developer or user has to do, so there is no documentation on it because none is needed. If you actually monitor the connection during a smart/delta update, while the UI shows the full size of the APK it actually downloads 1/4 or less of that.
It is absolutely enabled. It is absolutely working. There is no conspiracy about this. It is one of the reasons most updates take hours to propagate.
You complained about managing thin binaries, so I don't see how the developer managing that would improve anything, not to mention that it adds difficulties to cryptographic signing and verification.
What does "too little, too late" mean? Is Android now doomed?
Android updates have been incremental updates for three years now (introduced at the 2012 I/O, and immediately enabled). Your point on that is confused in any case -- why can't it do delta updates (it does...), and why can't the developer do it, but also why does the developer have to do it? You're incredibly complaining about a situation you invented.
And larger APKs are a problem because now the ridiculously easy tools that Google already provides (generating thin binaries for varied targets is extraordinarily simple. A bug regarding expansion files...what is the point of even linking that?) will somehow be unused?
Your post is a very poorly informed rant. I have no idea how it sits on the top.
The other comment about electronics is completely off the mark as well -- people often see financial transactions that don't seem to make logical sense (whether pricing bots that recursively keep pricing off of each other, as in the linked story, or prices that seem too good to be true, which more likely are gray market or arbitrage) and immediately explain it as money laundering. But consider the electronics sales, where the premise is that people are selling electronics that they apparently bought from Amazon using gift cards under the market just to launder cash.
There is an enormous financial black hole that is just as vulnerable to inspection as simply depositing $1,000,000 in cash in your account. The whole point of money laundering is not only to legitimize the output, it's to make the sources untraceable and arguably viable as well.
The components of a transaction, particularly for the sales of goods, cannot simply appear out of nowhere, or they've done absolutely nothing in the way of money laundering. The people who will ever care about this (the ones who money laundering is constructed to fool) aren't so naive, and if you're selling 100,000 hard drives to justify your income, they're going to ask where you got the hard drives, and demand a financial trail.
Cash businesses that have little variable costs outside of manpower (such as carwashes, laundrymats, even some small restaurants, or selling small crafts on Etsy) are absolutely lucrative tools for money laundering, and can only really get caught if put under heavy scrutiny (e.g. car wash with 10 cars over the week claims revenue of $100,000). As are casinos, and Vegas was built on money laundering -- there are few checks on how much you spend, so whether you spent $1,000,000 in unexplained cash to leave with $950,000 in legitimate winnings, or $10 in legitimate cash to leave with $950,000 in legitimate winnings, it's almost impossible to prove.
There are many, many financial vehicles that are used for money laundering, including life insurance. Selling hard drives on Amazon is not one of them.
I worked for years on AML systems for banks. This isn't money laundering. Indeed, I don't believe I've ever seen a "this is money laundering!" comment on a social news site that wasn't entirely and completely off the mark of real money laundering, but just seems to be a go-to for things that people don't understand.
VW claimed to have a trick that removed the need for it on their smaller, lighter cars. But that trick was a trick that only allowed them to pass EPA tests.
Both of those platforms use Urea systems, as do larger and more expensive VW/Audio vehicles. The issue is purely in the small, inexpensive vehicles.
The NOx problems were mostly resolved through the injection of urea into exhaust gases (e.g. AdBlue), dramatically reducing NOx emissions while leaving the efficiency and power unaffected. Urea systems add an extra cost and complexity to the vehicle though (not to mention that you need to top up your urea additive occasionally), and VW seemed to find a loophole that allowed them to make small, inexpensive cars without urea injection. They did this by injecting fuel into the exhaust in the absence of Urea, but to achieve the same effect. But this can gunk up the NOx trap if used endlessly (it is far less precise than urea, obviously), reduces fuel economy, etc, so they built this One Little Trick that only actually does that during identified tests.
The primary revenue source of many of these sites are ad clicks (impressions often don't matter). If the function paying the bills are ad clicks, and site stickiness really isn't a thing anymore (nowadays we're all directed by social news, Facebook, etc. Few of us visit specific sites), why not abuse the users that do come by.
A principal web design facet in the past was the notion that you pre-size all of the elements, such that the content layout is static. This basic facet has largely disappeared -- despite being monumentally simple -- and the only rational explanation is that moving content is profitable.
And for sure it is a terrible long term strategy. But the problem is that it's a tragedy of the commons -- your ad payout on most networks is based upon the group norms, not on your own site norms. So if everyone else is click tricking users, your own per click payment drops, so the only viable solution is to join the race to the bottom.
Aside from bot traffic, a significant percentage of "legitimate" traffic seems, anecdotally, to be engineered accidental clicks -- the mobile site that is constantly pushing content around in the hopes that one of your screen interactions accidentally yields an ad click. As one of an endless number of examples, a well respected, major recipe site has a mechanism to change the servings, and first you have to click on a "servings" button, and then on the actual serving count. After clicking on the servings, several hundred milliseconds later an ad appears exactly where the count input is, and clearly considerable engineering effort went into designing this, and many other, accidental interactions.
For what? I can only speak for myself but my immediate reaction is to click back and feel annoyed, and consider ad blocker options. It has never led to engagement or a purchase. Ever. The end result is that the performance of ads simply collapses, and sites have to get even trickier to entice accidental clicks. Rinse and repeat.
If you work in the "trick click" space, you are just dooming yourself. It is a race to the bottom.
The GM issue was enormous for literally years. Further the GM issue -- where key assembly had less torsion than expected, leading to the possibility of heavy keychains or unintended hits turning off the vehicle -- was never shown to be anything more than an isolated engineering mistake by a few engineers, who then actively covered up their own mistake. GM wasn't profiteering by having less tension than expected -- it didn't sell them cars, and it didn't save them money. The malice was not profiteering or circumventing. And for that they paid a $900 million dollar fine, and will pay out billions in lawsuits in virtually any case where the key turned off, even if it was actually operator error.
GM is in no universe blameless, but considerations that hold it like murder are irrational.
VW actively and intentionally misled consumers and regulators to sell cars promising mileage and power levels they don't actually achieve without actually cheating the system. They sold hundreds of thousands of cars -- at the cost of significant air pollution (some 200,000 Americans, and millions worldwide, are estimated to die from air pollution yearly) -- based upon these essentially lies. They actively promoted their eco-friendliness, and their great fuel economy, neither of which are actually true in concert.
After my post has been moderated down to the abyss, Marco has announced that he has given the app code to Ghostery, who'll certainly release an app in short order. And for which all logic states Arment will receive financial considerations.
My post above is completely accurate. The moral grandstanding is an embarrassment, and it's worse how well this noise works on HN.
Bringing up writing a compiler in relation to SoC design is, in itself, absurd. It undermines the expert claim to begin with. Waving one's hands at "industry mumbo jumbo" (even ARM reference architectures) and alluding to your own claims of knowledge is...incredibly ignorant. It is so far below what HN aspires to be it boggles.
It is what they said that discounts the mere possibility that they have even a basic layman knowledge of the topic, much less are an expert.
"I am embarrassed for you because you have seemed to be very mean and dismissive."
Did you read what DannyBee was saying at all? In response to empirically proven, well backed statements they disagreed, did the knowing wink and patronizing pat on the back, and pretended to have more knowledge based upon a growing volume of claims (first "write compilers", then "toolchain", then "toolchain bringup", none of which have anything to do with SoC-targeted schedulers). I didn't fire the first shot in being "mean and dismissive", and considering how profoundly ignorant this whole discussion is I was being as kind as possible.
It's actually interesting: You have no idea what my qualifications are, or my interest in this topic. Nor do I expect anyone, which is exactly why I cite actual data and information, not just my wink-wink/trust me/"don't believe those SoC fatcats" knowledge.