official word is out, x86 murders arm on every front...


Hopefully they can pull off the modular design (ie. Pandora CPU core board + peripheral board) for Pandora 2.

That way the SoC can be updated by swapping a module only. That would open a whole new set of options (in addition to easy upgrades).
Yeah, a product without a planned obsolescence would be really cool. 
It's not like OpenPandora guys can release a new SoC core board every 7 months like certain company, they don't even have the resources for that.  ;)
Well, I don't know, was just an idea. Think about what happened with the Nubs / DPad, they got slapped into a new case and voilà, ICP was born. OpenPandora could have a whole range of products all backed by the same modular SoC core board.
 
Last edited by a moderator:
^ which also shows that no matter what people discuss in this subforum, by the time the P2 is designed it's already old news and by the time the P2 comes out it will be recognised as obsolete.

This subforum is so useless it's funny :)
You don't know that. Pandora's hardware got dated so quickly because Pandora took 1.5 years longer than anticipated before it started shipping. It's a good faith assumption that the next one they build won't necessarily take so long and have so many problems.

Originally Craig was talking about releasing something late 2013, although now I doubt that'll happen. But if it did SoCs released early next year would be the right target to look at.
Well, it's dated, I guess, but I still don't see anything like the original 600mhz version with 256mb or RAM on the market place. Sure there are ones with faster processors and more RAM, but none with the keyboard.

And doubly so with the 1ghz units as they're more competitive performance-wise.
 
<Binky repeats himself>

The 3DS has a 320×240 screen - its pointless, outdated and has no hope of selling in the 2013 marketplace
 
Someone doesn't have to jump in and mention that the Pandora isn't obsolete every time someone else says that the hardware got dated fast. I wasn't saying anything to the contrary. You don't have to defend it.

the 3ds has a 800x480 top display
Nope, it's two 400x240 displays interleaved.
 
Someone doesn't have to jump in and mention that the Pandora isn't obsolete every time someone else says that the hardware got dated fast. I wasn't saying anything to the contrary. You don't have to defend it.

the 3ds has a 800x480 top display
Nope, it's two 400x240 displays interleaved.
yeah you are right, besides that this thread shouldnt be about the p1 we should be looking at the pros and cons with x86 in p2, this time around the x86 isn't hot, power hungry nor way out of reach p2
 
This power envelope is still too high for P2. Tegra 3, at least in this configuration, would be a poor choice too. That doesn't really matter though. Boiling it down to "ARM vs x86" is stupid. I'd much rather have a 2+ core Cortex-A15 or even better something with big.LITTLE Cortex-A7s, on TSMC 28nm or Samsung 32nm or 28nm. While x86 gets lots of praise because of doing better in shitty JS code (as in, better than it does anywhere else, probably has a big software advantage) I care about native performance, and while you think that x86 has a monopoly on exclusive optimization you're dead wrong. You'll see more what I mean later, but you're going to miss out on other things if you go away from ARM.

But you're acting like you're bringing breaking news here. I brought up Medfield and Clover Trail like a billion times in the other thread. I constantly said "if you want to use x86 in a small mobile device these are your options, not Ontario or even Hondo." Of course you ignored me but now when you read it somewhere else act like it's breaking news. So I'm not going to have much positive to say in response.

BTW, on the other thread you got a bunch of people who said they want x86-64 but only one person said plain old x86. Unfortunately for you Medfield and Clover Trail are 32-bit only.
 
Last edited by a moderator:
This power envelope is still too high for P2. Tegra 3, at least in this configuration, would be a poor choice too. That doesn't really matter though. Boiling it down to "ARM vs x86" is stupid.

But you're acting like you're bringing breaking news here. I brought up Medfield and Clover Trail like a billion times in the other thread. I constantly said "if you want to use x86 in a small mobile device these are your options, not Ontario or even Hondo." Of course you ignored me but now when you read it somewhere else act like it's breaking news. So I'm not going to have much positive to say in response.
and you are the only one with an opinion?
 
What does that mean? The point is I brought it up several times, you never once responded then, but now when someone reports about it you act like it's big news. Of course I don't feel like talking to you much when pretty much everything I type goes right through your ears.
 
Last edited by a moderator:
What does that mean? The point is I brought it up several times, you never once responded then, but now when someone reports about it you act like it's big news. Of course I don't feel like talking to you much when pretty much everything I type goes right through your ears.
I saw all the stuff you said and I believe every word you say because you seem to know your stuff and I respect your opinion but whenever I bring up a point you are always the first to just shoot it down, so there isn't much I can do but just move past your comments.
 
It's not my fault you're always saying things that have problems with them. You might think that I'm singling you out but I've never done that, I've always responded specifically to whatever you were trying to say. If you ignore me because you don't like being wrong about anything then that's really your problem.

The majority of your threads can be summarized as "hey why isn't anyone doing this thing that's totally different, it sounds great, we should do it." So of course chances aren't going to be great that there aren't real reasons why people aren't doing it.
 
One interesting information here about the tests from the very first posts:


This wasn't a comparison between ARM and x86. It was a comparison of ARM and x86 running Windows RT.


Windows RT doesn't fully support the Tegra 3. It doesn't use Tegras power saving feature - the Ninja chip (if I remember the name correctly).


You can't use this as a general comparison between ARM and Intel, because comparing the power usage when the ARM SoC has it's internal powersaving disabled doesn't make sense.


They just wanted to show for WINDOWS RT the Intel is better.
 
One interesting information here about the tests from the very first posts:


This wasn't a comparison between ARM and x86. It was a comparison of ARM and x86 running Windows RT.


Windows RT doesn't fully support the Tegra 3. It doesn't use Tegras power saving feature - the Ninja chip (if I remember the name correctly).


You can't use this as a general comparison between ARM and Intel, because comparing the power usage when the ARM SoC has it's internal powersaving disabled doesn't make sense.


They just wanted to show for WINDOWS RT the Intel is better.
would the 5th core really help the average power consumption that much? maybe for idle but for most workloads wouldn’t it be all 4 cores?
 
No of course most workloads aren't using all 4 cores. All the Javascript ones are even single threaded (when Anand says Kraken is multithreaded he is wrong, try running it yourself and you'll see it's purely single threaded). Unfortunately the masses will assume otherwise and believe that one Saltwell core outperforms two Cortex-A9 cores put together. Often times you will have two threads active but while one does a lot of work the other only does a little work, and this scenario is well suited to HT instead of two cores.

Maybe Anand should have included core utilization graphs alongside the power numbers. I don't know why review sites never do this. In Windows it should be especially easy.

The companion does still help with more than idle, look at the power consumption charts, they're not straight lines. Utilization is constantly ramping up and down. I don't know where the companion core kicks in, AFAIK it'd be below 500MHz. So it'll be beneficial even for some parts of these workloads where the CPU is being used. Unfortunately Tegra 3's model only lets you use the companion core when nothing else is used (that's really all they could do with Cortex-A9), so it's pretty limited. Still, you'd get some tasks that are doing the heavy lifting elsewhere like video or other heavily accelerated processes, but they still need to do something on the CPU outside of idle it all the time. Here the low power core helps.

4 core Cortex-A9s (and pure Cortex-A15 systems) are difficult to schedule well with asynchronous workloads, because the entire chip runs at the same frequency and voltage. So your choice is to run more cores at a lower frequency or fewer cores at a higher frequency. If you make a bad decision here (or worse, run all cores at a high frequency) then you'll get bad results. I don't know how good of a job MS has done optimizing WinRT for this sort of workload, but if they can't support the companion core mode at all I'm not optimistic). This is all the more reason why someone like Anand should include with their review side by side information listing what cores are active and what the frequency is. It'd be just as interesting for Atom which has HT and Turbo, so you can see what it's profile is like for utilization of both, and how well Windows is scheduling threads vs cores. With stuff like this you could do some real analysis. Unfortunately people are more interested in pissing contests than real analysis and that's what review sites cater to.

Personally, I find big.LITTLE a lot more attractive because you can run a small number (1-2) of strong Cortex-A15 cores along side active (1-4) Cortex-A7 cores, which will do well with asynchronous workloads the same way Intel's HT does. Bizarrely, rumors indicate that Silvermont is actually dropping HT, which IMO is Atom's number one trump card (although it has some other advantages). We'll have to see how that all plays out. Particularly if four Silvermont cores will be totally asynchronous themselves.
 
Last edited by a moderator:
No of course most workloads aren't using all 4 cores. All the Javascript ones are even single threaded (when Anand says Kraken is multithreaded he is wrong, try running it yourself and you'll see it's purely single threaded). Unfortunately the masses will assume otherwise and believe that one Saltwell core outperforms two Cortex-A9 cores put together. Often times you will have two threads active but while one does a lot of work the other only does a little work, and this scenario is well suited to HT instead of two cores.

Maybe Anand should have included core utilization graphs alongside the power numbers. I don't know why review sites never do this. In Windows it should be especially easy.

The companion does still help with more than idle, look at the power consumption charts, they're not straight lines. Utilization is constantly ramping up and down. I don't know where the companion core kicks in, AFAIK it'd be below 500MHz. So it'll be beneficial even for some parts of these workloads where the CPU is being used. Unfortunately Tegra 3's model only lets you use the companion core when nothing else is used (that's really all they could do with Cortex-A9), so it's pretty limited. Still, you'd get some tasks that are doing the heavy lifting elsewhere like video or other heavily accelerated processes, but they still need to do something on the CPU outside of idle it all the time. Here the low power core helps.

4 core Cortex-A9s (and pure Cortex-A15 systems) are difficult to schedule well with asynchronous workloads, because the entire chip runs at the same frequency and voltage. So your choice is to run more cores at a lower frequency or fewer cores at a higher frequency. If you make a bad decision here (or worse, run all cores at a high frequency) then you'll get bad results. I don't know how good of a job MS has done optimizing WinRT for this sort of workload, but if they can't support the companion core mode at all I'm not optimistic). This is all the more reason why someone like Anand should include with their review side by side information listing what cores are active and what the frequency is. It'd be just as interesting for Atom which has HT and Turbo, so you can see what it's profile is like for utilization of both, and how well Windows is scheduling threads vs cores. With stuff like this you could do some real analysis. Unfortunately people are more interested in pissing contests than real analysis and that's what review sites cater to.

Personally, I find big.LITTLE a lot more attractive because you can run a small number (1-2) of strong Cortex-A15 cores along side active (1-4) Cortex-A7 cores, which will do well with asynchronous workloads the same way Intel's HT does. Bizarrely, rumors indicate that Silvermont is actually dropping HT, which IMO is Atom's number one trump card (although it has some other advantages). We'll have to see how that all plays out. Particularly if four Silvermont cores will be totally asynchronous themselves.
so what do you think would be a fair test environment to measure power consumption between the two, linux?

do you know of any manufactures that gates each cpu seperately?

I read somewhere that these will drop HT and use out of order processing, have you heard this rumor?

also big.LITTLE is arms next proposition for performance/watt, what do you think intels will be? dropping atom on its 22nm process ,waiting for its 14nm process or the weird near threshold voltage stuff?
 
I never said this wasn't a fair environment to measure power consumption. I said I wanted more information to show what the cores are actually doing, something that should be easily possible in Windows. I posted a comment on that thread asking Anand if he can do this.

All of the manufacturers are offering individual power gating for each CPU core. The only exception I can even think of was the old Tegra 2 which only let you turn both cores off. What they don't all offer is asynchronous DVFS, where each cores have a different clock and voltage rail. This is more expensive because it needs more voltage regulation and is a more complex design, also having consequences for latency in shared structures (probably why async cores are typically not coming with shared L2 cache). Qualcomm's Scorpion and Krait CPUs can do it. From what I can find in the datasheet Z2760 doesn't have asynchronous power rails per core but I don't know about clocking. big.LITTLE should provide two separate voltage/clock domains for the A15 and A7 parts so that gives a nice balance between the two approaches, but otherwise Cortex-A9 and Cortex-A15 are both incapable of asynchronous operation on their own.

Making Silvermont a more out of order core is a given. I don't know anything more about the non-HT rumor than that it exists on that slide. I haven't heard anything else about what they'll do to improve perf/W. I doubt they're anywhere close to making near threshold usable for a product like Atom, it'll most likely come in other more throughput oriented stuff first. Even Atom's single threaded performance vastly exceeds what they've been playing around with there. Of course they'll move it to 22nm and 14nm, and things will get more interesting for them when they do because they'll have a real process advantage. Right now they just look like they do in shoddy comparisons vs dated stuff like Tegra 3.

One other thing about the article that I haven't seen anyone mention. AT made it clear they did all the tests and Intel had no influence since they only provided the test hardware, yet we don't know for sure that they didn't cherry pick the Clovertrail tablets (or even the Tegra 3 ones) to procure the most favorable results they could. Variations in power consumption from the high end to the low end of a bin can be fairly substantial. I'm not saying they did this but we can't know for sure. You should never fully trust an experiment that's been setup by a partial party. The only way to really check is to start picking other ones at random, from the open market, and see how they do.
 
The main advantage that a x86 device seems to offer won't materialize if most of those windows desktop games people want to run, run too slowly.


From a software standpoint, I'd rather see Android (arm) software being run on a SoC faster than what the software was designed-for, than Windows (x86) software running on a SoC that is slower than the desktop PCs it was designed-for.


That's not to say that dosbox and wine on a x86 device wouldn't be fun, just that for new games, Android + Arm seems a better fit for a portable device.
 
Last edited by a moderator:
someone ported win rt onto the htc hd2, maybe you can run it on the (new) pandora also?

isn't the same as a full x86 win8 but might cover some need to switch to power hungry x86 chips.

also 14nm will not be done in 5 years i think, they just started going to the 20th something nm and they have to do a lot more to make it work on 16nm...

link: http://www.slashgear.com/windows-rt-ported-to-htc-hd2-27262308/
 
Back
Top