3 ms·

I'm not sure how many experts in how many areas of the actual phones and phone oses we are talking about have to keep telling you you are wrong before you start

I'm not sure how many experts in how many areas of the actual phones and phone oses we are talking about have to keep telling you you are wrong before you start believing it (so far, looking at this thread, it stands at 3), but given your demeanor, as i stated, i don't really have an interest in continuing this conversation. The fact that your response to someone like swetland is "Not to mention that their comment is simply dated and wrong now regardless." is hilariously arrogant and amazing. I'll just continue to find it funny that you want to cite chip manufacturers (who uh, might be slightly self-serving in selling their architectures, and produce zero actual phones except for samsung. Except, of course, that the division of samsung that produces the phones is separate and does not really talk to the chip making division. I'm sure you know this), when i am talking about the actual qualification and testing of real world phones, and not "whatever random crap they made up to put in their marketing material". You can try to gussy that up as "actual field observations of SOC vendors" or whatever, but that just shows further ignorance in how SOC vendors actually operate. Again, I urge you: Buy an evaluation board or two. They are cheap. Put an OS on them. Try out what you claim is true. Measure the power draw. I think you will be surprised. Have a good one!

schedulingOn 11y ago
I have never commented on HN before, but this thread drew me to actually create an account. It is a great example of a conversation gone awry, and people putting personalities over facts. As someone who works on scheduling code in one of the aforementioned architectures, inversionOf is correct on all counts, at least in regards to these architectures and power to performance. They may be rude and obnoxious, but your claims through this thread have been entirely off the mark and do not serve the community well. Workloads are monitored for intensity. If they fall low enough they are migrated to the little core because it offers a much better total performance per unit of work. The frequency of the cores (whether big or little) are adjusted to fit the workload. If the workload is really low, we put the core to sleep. Sleep is, exactly as stated, the last possible, coarsest measure. Sleep is not a replacement for frequency scaling. Frequency scaling achieves a half measure of what core migration achieves. You don't have to believe my credentials, but you claim that "3 experts" have supported your stance. That simply isn't true. No one who works on scheduling algorithms for these platforms would support your claims.

schedulingOn 11y ago

I have never commented on HN before, but this thread drew me to actually create an account. It is a great example of a conversation gone awry, and people putting personalities over facts. As someone who works on scheduling code in one of the aforementioned architectures, inversionOf is correct on all counts, at least in regards to these architectures and power to performance. They may be rude and obnoxious, but your claims through this thread have been entirely off the mark and do not serve the community well. Workloads are monitored for intensity. If they fall low enough they are migrated to the little core because it offers a much better total performance per unit of work. The frequency of the cores (whether big or little) are adjusted to fit the workload. If the workload is really low, we put the core to sleep. Sleep is, exactly as stated, the last possible, coarsest measure. Sleep is not a replacement for frequency scaling. Frequency scaling achieves a half measure of what core migration achieves. You don't have to believe my credentials, but you claim that "3 experts" have supported your stance. That simply isn't true. No one who works on scheduling algorithms for these platforms would support your claims.