To implement the same lockless multithreaded algorithms on ARM, you'd have to insert explicit barriers; how do you think that would affect its performance relative to x86, which has much stricter reordering constraints?
How does POWER (which has a very similar memory model to ARMv8) fare against x86? It's not as clear-cut as you make it out to be. Explicit barriers amount to bus traffic and that's what adds the overhead (in performance and power). On x86, you're paying that cost whenever you have cache lines aliased across cores, even if you don't need it. On ARM, you only pay the cost when you need it. If you're programming with the C[++]11 concurrency model, then the compiler will sort out the barriers for you and there's some work (initially by one of my students, now by someone at Google) on optimising away redundant barriers.
You'll also note that recent x86 versions include relaxed memory operations that allow you to get some of the savings back.
If I'm NOW understanding you correctly, you're saying that the big core is better IF the pause is long enough to enter low-power and sleep long enough to make it worth it, correct?
Kind of. The big core is usually able to perform more computation per Joule, but uses more power per Watt when in its high-power state, so if you can complete some work and sleep the big core is usually better. If you have a constant stream of work, the little core is better.
Further, I'm reading between the lines and thinking you're saying that on a phone, that's normally the case - that the 53 cores aren't used often, or shouldn't be. Is that correct?
No, they're both used, but it isn't always a clear-cut decision which one is optimal. There are some other issues too. They don't have a shared L1 cache, so you take a small performance hit every time you migrate between them.
A phone in standby mode typically has a load of small non-interactive wakeups. These are almost always better to do on the big core, because they also involve powering other components so the win from finishing earlier is even bigger. In interactive jobs, it can vary a lot depending on the application.
Trying to work out exactly when you should run things on different cores is an interesting open research problem. It's going to get harder, because big.LITTLE is only the first step. Future iterations are likely to have lots of different cores tuned to specific workloads.
The other interesting thing to note about big.LITTLE is that (aside from the first-gen Samsung chips where they fucked up cache coherency), its not an either-or choice: you can have one big core and two little cores powered, if that makes sense for your workload.
If I'm understanding you correctly, you're saying it only saves power to use the little cores if there is io involved, such as a mobile network which is obviously much slower than the CPU cores. Or maybe storage device, like and SD card. Or any user interaction.
No, I'm saying that it saves power to use the little cores if you have a load of interrupts that prevent the core from going to sleep, but are not CPU-bound. For some interactive tasks (lots of moderately demanding apps), you're CPU-bound for short bursts but you can then put the core to sleep and wait.
User interaction is often on a timescale where you can put the core into a low power state while you wait for a ponderously slow user (in comparison to CPU speeds) to press a button. Simple animations can run on the GPU with no CPU involvement at all. When the user presses a button (or the screen), you wake up and do something quickly, then go back to sleep. The big core is often better for this.
The little core is better for things that you can't complete early and then sleep. The mobile network and SD card are terrible examples for your facetious little rant: they both deliver bursts of data tied to an interrupt, so are often ideal for the big core, depending on how quickly the big core can enter a low power state. The best example for the little core is mostly GPU-bound games that have a render loop that requires very frequent CPU-driven updates but without much work being done on the CPU each iteration. There isn't a long enough pause between each one to be able to enter a low power state, but if the A7 can keep up with the demand then it will be more power efficient.
If the world were as simplistic as you're trying to make it out to be, there'd be no point in putting the big cores on at all. Before you try to sound patronising again, please go and read some of ARMs docs. They cover all of this, in a lot of detail, and list some open problems (some of which they're talking to us about on a fairly regular basis).
The web does need the big centralised systems to start aggressively censoring, to provide a clean and easily understandable case study of why they're a bad idea.
You believe that being paid for doing something without being asked to is natural? Creating an original work is hard, copying one is trivial. Copyright is an attempt to promote the first by granting people who create things a monopoly on the second. It's about as artificial as you can get, forcing the market to value something that is intrinsically easy, not something that is hard.
I don't like the "granted" word here. The book was created by the author and it belongs to him.
The book belongs to him (probably - contracts may say otherwise). The rights associated with a monopoly on copies of it are an entirely artificial construct that the government agrees to enforce to encourage creation.
No, I'm not claiming that they're wrong - I'm repeating things that they've told me. We have a project with them to investigate good power-efficient scheduling behaviour for precisely this reason: The big.LITTLE configuration does not mean that it's always better to use the little cores, it means that it's better to use the little core for long-running tasks that have a lot of I/O and so can't put the core to sleep, but aren't CPU-bound. If you have something CPU-bound, then you're often better off doing it on the big core and then going back to sleep. Detecting these workloads is not a trivial problem.
There are also some corner cases that are also quite interesting. The A7 has lower latency access to L1 than the A15, so for workloads with a very small working set, running them on the A7 can actually be faster (this shows up in one of the SPEC benchmarks).
There was a panel of authors a few years ago arguing for shorter copyright because it would strengthen their bargaining position with their publishers. Most books make 90% (or more) of their profits within the first 7 years of publication, so there's little incentive to extend it and publishers survive by constantly producing a stream of new material. One of the reasons that they like eBooks is that it gives them a way of monetising their back catalogue, but for a lot of authors being able to give away their earlier works would be great advertising and make it easier to sell the new one without the backing of a big publisher (which is part of the reason that publishers are against it).
Most software is completely obsolete within 7 years, almost nothing lasts 14. Maybe people would have been happy with a public domain Windows XP, but that's a pretty rare example (and a company can still make money producing security updates for such old software, even if it's in the public domain. The new patches will still be covered by copyright).
And how many people in the USA have written to their elected representatives to tell them that they will not vote for any candidate that is in favour of copyright extensions? My guess is that it's a sufficiently small number that even a relatively small campaign contribution has a much larger impact on the elections...
Copyright is a government-granted monopoly. How can you possibly argue that the government is not providing value for something that exists solely as a result of government action?
No. As the other poster says, these cores consume negligible amounts of power when not in use. The performance per Watt of the bigger cores can often be better, so it can consume less energy to power one of the big cores for 250ms than power the little core for 1s, yet still get the same (or more) work done. If your OS scheduler is able to coalesce events then this can be a big energy saving (and, remember, it's energy not power that matters for battery life: your battery can - more or less - supply a fixed amount of energy per charge).
The granparent said 'anti-monopoly' and 'anti-oligopoly' (although an oligopoly is more commonly referred to as a cartel these days). The big five record labels definitely count as an oligopoly.
A lot of the games I've bought from GOG.com have been £2-3. I wouldn't have bought them at £10-20 - many take me 6 months or so to get around to playing, but at that price (i.e. less than a pint of beer) I'm willing to buy a game that looks like it might be fun, just on the off-chance that it is. For some games (e.g. the Daedalic and Wajet Eye ones) I've then gone and bought the publisher's entire catalog after trying a couple, because I know that I'm definitely going to get good value for money from them. Even the short games are a few hours of entertainment per pound.
If you can't make money selling the product at a reasonable price then there wasn't enough demand for the product to justify making it. I just paid about £10 for the remastered edition of Grim Fandango (and pre-ordered it). I imagine that this is a lot more than the publisher needs to cover developer costs, licensing costs, and make a fairly good profit, but it's a price that I'm very willing to pay because I enjoyed the original a lot (but played it on a friend's computer so don't own a copy and haven't been able to re-play it, plus apparently getting it to work on a modern OS is somewhat painful). I'm about a quarter of the way through it so far, and it's money very well spent.
Your question applies to any goods or services: if you can't sell it for enough money to cover the costs of making it, then don't make it. Often the optimal price is non-intuitive. There was a Harvard study a few years ago that found that the optimal price for maximising profit on music was about 5/track. At this price, people are willing to buy an album or two because a friend recommends it, often without listening to it (or perhaps only having heard one track) first. If you pay a dollar for an album and only listen to it a couple of times, you don't feel too bad. If you pay ten dollars, you do and you think a lot more carefully about future purchases. I've bought some games from GOG for a couple of dollars that I've played for under half an hour before getting bored with them. At that price, I don't care and I'm willing to take a chance on the next one.
If I were trolling, I would have said 'typical American' - someone who obviously believes that, because New York has ludicrous regulatory capture, that's how all taxi regulations work.
This seems to be increasingly common. I recently had a taxi driver ask me which way I wanted to go. He wanted to go a longer route, because he knew that the direct route would have terrible traffic at that time of day. I knew the city and agreed, but apparently a lot of passengers are insisting that he take the direct route and complaining if he doesn't. They're also then complaining about the delays, which is why he now asks - he can tell them it was their decision when he gets caught up in traffic.
Not those shelves. The advantage of the bread that's full of preservatives is that you can ship it more slowly and leave it in the warehouse / shop storeroom longer, which helps even out demand spikes and dips, meaning that you can sell most of it. The fact that it then only lasts a day or two in your house if you buy it at the wrong time is even a feature as it means that you'll go and buy more the next day.
The same is true for fruit and vegetables. It can take a month (sometimes longer) for them to get from the farm to the supermarket. If you buy from local farm shops then they'll last far longer because you're not using up most of their lifespan before you even see them on the shelves.
if the profits were made in tax free countries, so be it.
If the profits were made entirely by employees working in that country, selling to people in that country, goods or services produced in that country, then you might have a point. In most cases, they're made from employees working in other countries, selling in other countries, and doing various tricks to book the income somewhere else.
No one objects to companies that are based in the Cayman Islands, working and selling there, paying no tax. People object to companies in the US and EU doing business there and benefitting from the infrastructure yet somehow paying a wholly owned subsidiary in the Cayman Islands a trademark license that happens to be of equal value to their total profits (or one of the various other similar dodges).
Which is also annoying, because you're going to want a different kernel and a different set of packages (the A7 supports Thumb-2, the ARM11 on the old RPi didn't and Thumb-2 gives much better code density / i-cache usage, which leads to better performance). The main advantage of the RPi was that it was a known ARM hardware configuration that had a few million deployed and so was worth supporting by operating systems. Fragmenting this risks putting them in the same category as all of the other ARM boards.
I've also got my magnifier configured so that I can use CTRL+ALT + Mousewheel or WIN+Mousewheel to zoom in/out very quickly, and CTRL+ALT+Middleclick to toggle invert.
The zoom feature in OS X is configurable, but the default combination is control+mousewheel, so I'm not sure what it is that you prefer about the Windows one.
Some of us grew up in between the end of the 'OMG Communists!' era and the start of the 'OMG terr'rists!' era. The rest of you probably shouldn't be allowed to vote.
They'd have had to dig underground ducting in to everybody's garden. How did they do it without us noticing?
Presumably people did notice. The telephone connection to both of my last two houses comes in at the front, but there was a telegraph pole in the back of both with a wire going into the back (and then terminating). In both houses, the wire eventually fell off the back. I presume that the previous owners did notice when they re-did their telephone wiring...
As I said above, just because the poles are there doesn't mean that they're carrying anything. When they run the underground cabling, they generally don't bother properly disposing of the telegraph poles: they just let them fall down.
I have a house on a street lined with telegraph poles in the UK too. The poles run wires to everyone's house. The same was true of the place I lived before moving there. In both cases, the wire fell off my house while I was living there. It hadn't been connected to anything inside the house for a very long time - telephone service came in on the other side of the house, underground. They just never got around to removing the poles and the above-ground wires that didn't have a signal going through them.
Slashdot Mirror
To implement the same lockless multithreaded algorithms on ARM, you'd have to insert explicit barriers; how do you think that would affect its performance relative to x86, which has much stricter reordering constraints?
How does POWER (which has a very similar memory model to ARMv8) fare against x86? It's not as clear-cut as you make it out to be. Explicit barriers amount to bus traffic and that's what adds the overhead (in performance and power). On x86, you're paying that cost whenever you have cache lines aliased across cores, even if you don't need it. On ARM, you only pay the cost when you need it. If you're programming with the C[++]11 concurrency model, then the compiler will sort out the barriers for you and there's some work (initially by one of my students, now by someone at Google) on optimising away redundant barriers.
You'll also note that recent x86 versions include relaxed memory operations that allow you to get some of the savings back.
If I'm NOW understanding you correctly, you're saying that the big core is better IF the pause is long enough to enter low-power and sleep long enough to make it worth it, correct?
Kind of. The big core is usually able to perform more computation per Joule, but uses more power per Watt when in its high-power state, so if you can complete some work and sleep the big core is usually better. If you have a constant stream of work, the little core is better.
Further, I'm reading between the lines and thinking you're saying that on a phone, that's normally the case - that the 53 cores aren't used often, or shouldn't be. Is that correct?
No, they're both used, but it isn't always a clear-cut decision which one is optimal. There are some other issues too. They don't have a shared L1 cache, so you take a small performance hit every time you migrate between them.
A phone in standby mode typically has a load of small non-interactive wakeups. These are almost always better to do on the big core, because they also involve powering other components so the win from finishing earlier is even bigger. In interactive jobs, it can vary a lot depending on the application.
Trying to work out exactly when you should run things on different cores is an interesting open research problem. It's going to get harder, because big.LITTLE is only the first step. Future iterations are likely to have lots of different cores tuned to specific workloads.
The other interesting thing to note about big.LITTLE is that (aside from the first-gen Samsung chips where they fucked up cache coherency), its not an either-or choice: you can have one big core and two little cores powered, if that makes sense for your workload.
If I'm understanding you correctly, you're saying it only saves power to use the little cores if there is io involved, such as a mobile network which is obviously much slower than the CPU cores. Or maybe storage device, like and SD card. Or any user interaction.
No, I'm saying that it saves power to use the little cores if you have a load of interrupts that prevent the core from going to sleep, but are not CPU-bound. For some interactive tasks (lots of moderately demanding apps), you're CPU-bound for short bursts but you can then put the core to sleep and wait.
User interaction is often on a timescale where you can put the core into a low power state while you wait for a ponderously slow user (in comparison to CPU speeds) to press a button. Simple animations can run on the GPU with no CPU involvement at all. When the user presses a button (or the screen), you wake up and do something quickly, then go back to sleep. The big core is often better for this.
The little core is better for things that you can't complete early and then sleep. The mobile network and SD card are terrible examples for your facetious little rant: they both deliver bursts of data tied to an interrupt, so are often ideal for the big core, depending on how quickly the big core can enter a low power state. The best example for the little core is mostly GPU-bound games that have a render loop that requires very frequent CPU-driven updates but without much work being done on the CPU each iteration. There isn't a long enough pause between each one to be able to enter a low power state, but if the A7 can keep up with the demand then it will be more power efficient.
If the world were as simplistic as you're trying to make it out to be, there'd be no point in putting the big cores on at all. Before you try to sound patronising again, please go and read some of ARMs docs. They cover all of this, in a lot of detail, and list some open problems (some of which they're talking to us about on a fairly regular basis).
Gee, how did we possibly get from the 1600s to the 2000s without "Child Protective Services"?
By having lots of children to compensate for very high infant mortality. How did you think we did it?
The web does need the big centralised systems to start aggressively censoring, to provide a clean and easily understandable case study of why they're a bad idea.
You believe that being paid for doing something without being asked to is natural? Creating an original work is hard, copying one is trivial. Copyright is an attempt to promote the first by granting people who create things a monopoly on the second. It's about as artificial as you can get, forcing the market to value something that is intrinsically easy, not something that is hard.
I don't like the "granted" word here. The book was created by the author and it belongs to him.
The book belongs to him (probably - contracts may say otherwise). The rights associated with a monopoly on copies of it are an entirely artificial construct that the government agrees to enforce to encourage creation.
No, I'm not claiming that they're wrong - I'm repeating things that they've told me. We have a project with them to investigate good power-efficient scheduling behaviour for precisely this reason: The big.LITTLE configuration does not mean that it's always better to use the little cores, it means that it's better to use the little core for long-running tasks that have a lot of I/O and so can't put the core to sleep, but aren't CPU-bound. If you have something CPU-bound, then you're often better off doing it on the big core and then going back to sleep. Detecting these workloads is not a trivial problem.
There are also some corner cases that are also quite interesting. The A7 has lower latency access to L1 than the A15, so for workloads with a very small working set, running them on the A7 can actually be faster (this shows up in one of the SPEC benchmarks).
There was a panel of authors a few years ago arguing for shorter copyright because it would strengthen their bargaining position with their publishers. Most books make 90% (or more) of their profits within the first 7 years of publication, so there's little incentive to extend it and publishers survive by constantly producing a stream of new material. One of the reasons that they like eBooks is that it gives them a way of monetising their back catalogue, but for a lot of authors being able to give away their earlier works would be great advertising and make it easier to sell the new one without the backing of a big publisher (which is part of the reason that publishers are against it).
Most software is completely obsolete within 7 years, almost nothing lasts 14. Maybe people would have been happy with a public domain Windows XP, but that's a pretty rare example (and a company can still make money producing security updates for such old software, even if it's in the public domain. The new patches will still be covered by copyright).
And how many people in the USA have written to their elected representatives to tell them that they will not vote for any candidate that is in favour of copyright extensions? My guess is that it's a sufficiently small number that even a relatively small campaign contribution has a much larger impact on the elections...
Copyright is a government-granted monopoly. How can you possibly argue that the government is not providing value for something that exists solely as a result of government action?
No. As the other poster says, these cores consume negligible amounts of power when not in use. The performance per Watt of the bigger cores can often be better, so it can consume less energy to power one of the big cores for 250ms than power the little core for 1s, yet still get the same (or more) work done. If your OS scheduler is able to coalesce events then this can be a big energy saving (and, remember, it's energy not power that matters for battery life: your battery can - more or less - supply a fixed amount of energy per charge).
Do you also think that actors aren't artists, only playwrights? If so, you're using a very uncommon definition.
The granparent said 'anti-monopoly' and 'anti-oligopoly' (although an oligopoly is more commonly referred to as a cartel these days). The big five record labels definitely count as an oligopoly.
A lot of the games I've bought from GOG.com have been £2-3. I wouldn't have bought them at £10-20 - many take me 6 months or so to get around to playing, but at that price (i.e. less than a pint of beer) I'm willing to buy a game that looks like it might be fun, just on the off-chance that it is. For some games (e.g. the Daedalic and Wajet Eye ones) I've then gone and bought the publisher's entire catalog after trying a couple, because I know that I'm definitely going to get good value for money from them. Even the short games are a few hours of entertainment per pound.
If you can't make money selling the product at a reasonable price then there wasn't enough demand for the product to justify making it. I just paid about £10 for the remastered edition of Grim Fandango (and pre-ordered it). I imagine that this is a lot more than the publisher needs to cover developer costs, licensing costs, and make a fairly good profit, but it's a price that I'm very willing to pay because I enjoyed the original a lot (but played it on a friend's computer so don't own a copy and haven't been able to re-play it, plus apparently getting it to work on a modern OS is somewhat painful). I'm about a quarter of the way through it so far, and it's money very well spent.
Your question applies to any goods or services: if you can't sell it for enough money to cover the costs of making it, then don't make it. Often the optimal price is non-intuitive. There was a Harvard study a few years ago that found that the optimal price for maximising profit on music was about 5/track. At this price, people are willing to buy an album or two because a friend recommends it, often without listening to it (or perhaps only having heard one track) first. If you pay a dollar for an album and only listen to it a couple of times, you don't feel too bad. If you pay ten dollars, you do and you think a lot more carefully about future purchases. I've bought some games from GOG for a couple of dollars that I've played for under half an hour before getting bored with them. At that price, I don't care and I'm willing to take a chance on the next one.
If I were trolling, I would have said 'typical American' - someone who obviously believes that, because New York has ludicrous regulatory capture, that's how all taxi regulations work.
This seems to be increasingly common. I recently had a taxi driver ask me which way I wanted to go. He wanted to go a longer route, because he knew that the direct route would have terrible traffic at that time of day. I knew the city and agreed, but apparently a lot of passengers are insisting that he take the direct route and complaining if he doesn't. They're also then complaining about the delays, which is why he now asks - he can tell them it was their decision when he gets caught up in traffic.
Not those shelves. The advantage of the bread that's full of preservatives is that you can ship it more slowly and leave it in the warehouse / shop storeroom longer, which helps even out demand spikes and dips, meaning that you can sell most of it. The fact that it then only lasts a day or two in your house if you buy it at the wrong time is even a feature as it means that you'll go and buy more the next day.
The same is true for fruit and vegetables. It can take a month (sometimes longer) for them to get from the farm to the supermarket. If you buy from local farm shops then they'll last far longer because you're not using up most of their lifespan before you even see them on the shelves.
if the profits were made in tax free countries, so be it.
If the profits were made entirely by employees working in that country, selling to people in that country, goods or services produced in that country, then you might have a point. In most cases, they're made from employees working in other countries, selling in other countries, and doing various tricks to book the income somewhere else.
No one objects to companies that are based in the Cayman Islands, working and selling there, paying no tax. People object to companies in the US and EU doing business there and benefitting from the infrastructure yet somehow paying a wholly owned subsidiary in the Cayman Islands a trademark license that happens to be of equal value to their total profits (or one of the various other similar dodges).
Which is also annoying, because you're going to want a different kernel and a different set of packages (the A7 supports Thumb-2, the ARM11 on the old RPi didn't and Thumb-2 gives much better code density / i-cache usage, which leads to better performance). The main advantage of the RPi was that it was a known ARM hardware configuration that had a few million deployed and so was worth supporting by operating systems. Fragmenting this risks putting them in the same category as all of the other ARM boards.
I've also got my magnifier configured so that I can use CTRL+ALT + Mousewheel or WIN+Mousewheel to zoom in/out very quickly, and CTRL+ALT+Middleclick to toggle invert.
The zoom feature in OS X is configurable, but the default combination is control+mousewheel, so I'm not sure what it is that you prefer about the Windows one.
Some of us grew up in between the end of the 'OMG Communists!' era and the start of the 'OMG terr'rists!' era. The rest of you probably shouldn't be allowed to vote.
They'd have had to dig underground ducting in to everybody's garden. How did they do it without us noticing?
Presumably people did notice. The telephone connection to both of my last two houses comes in at the front, but there was a telegraph pole in the back of both with a wire going into the back (and then terminating). In both houses, the wire eventually fell off the back. I presume that the previous owners did notice when they re-did their telephone wiring...
As I said above, just because the poles are there doesn't mean that they're carrying anything. When they run the underground cabling, they generally don't bother properly disposing of the telegraph poles: they just let them fall down.
I have a house on a street lined with telegraph poles in the UK too. The poles run wires to everyone's house. The same was true of the place I lived before moving there. In both cases, the wire fell off my house while I was living there. It hadn't been connected to anything inside the house for a very long time - telephone service came in on the other side of the house, underground. They just never got around to removing the poles and the above-ground wires that didn't have a signal going through them.