ARM vs. X86. Lets vote
- Thread starter Askarus
- Start date
Exophase
Nothing good will ever come of Exophase.
Okay, please for a minute here completely ignore Intel's desktop market. Look at their mobile processors in isolation. Forget about this crap like "motherboard revisions", this is not some socketed processor you buy at Microcenter. Yes, they're releasing new products very aggressively now - so is everyone in the mobile world. At least those who are still remaining; inability to keep up is more or less why TI, Freescale, and ST-Ericsson have dropped out of making phone and tablet SoCs. But Samsung, Qualcomm, Apple, nVidia, and Intel are now poised to release major new SoCs roughly twice a year, as well as products for separate market segments.
The difference between Intel and the rest is not that they're going to have a more aggressive release schedule but that they're starting with a manufacturing lead ahead of everyone else. This gap is bound to go down eventually but it'll be at least a few years before that even starts to happen. Yes, it's inevitable that Pandora 2 will be obsoleted quickly, and that's okay. You can make the argument that paying for a huge premium just to get the status of having the very best wouldn't be wise, but you can't make an argument that comparative quality stops mattering entirely.
I get that people see "x86 vs ARM" where they should be seeing "laptop processor vs phone processor." I'm seeing this all over your posts (and others) and it's a misconception that should have changed ages ago. By the time Pandora 2 is out it probably will have changed a lot because there'll be a more Atom-based mobile products out there.
Not an FPGA. Just ARM processors paired with a GPU-like sea of parallel FP-capable processors. Probably lacking in enough fixed function hardware. Commercial failure for fairly obvious reasons.WeeeeI think we should shove in some FPGA's and then we can tell it when to be ARM and when to be an x86
Last edited by a moderator:
MrConfusion
Very Active Member
- Joined
- Apr 11, 2013
- Messages
- 331
I thought some changes to the motherboard were needed when P1 went 1 GHz? I really was thinking about P2 upgradeability, not desktop PCs...
Anyway, like I have already said earlier, as long as the system works, I don't care about the ISA... and in fact, like I've pointed out in other threads, I'd be a heavy user of x86 instruction set via Wine, possibly DOSBox, etc.
But with Intel there is this one thing:
http://gigaom.com/2009/04/08/intel-going-mobile-with-moorestown-pushing-nehalem-everywhere/
This article got released about the time I originally ordered the Pandora. And where are those mobile products now, 4.5 years later?
I know, I know... This Time It's Different. Well, in a few weeks/months we'll see (again, only This Time It's Different...)...
Intel's continuing lack of capability to get this right has created a strange psychological barrier for me, I admit that. But it's nothing a good phone sized product would not wash away.
I don't wish them to fail, quite the contrary, all competition is good competition. It's just that... They're Intel, right? They have failed so many times, so won't they just fail again?
See what I mean?
God Ginrai
Godmaster
I'm seeing "processor for desktops with ugly CISC instruction set and software that was written assuming that everyone has spare CPU cycles and RAM as well as a wall-jack power source (or battery the size of a disk drive)" versus "processor traditionally used in gaming handhelds with a cleaner, RISC instruction set and software that was been optimized so that it can run with less battery, cycles, and RAM"
-God Ginrai
Exophase
Nothing good will ever come of Exophase.
Intel's difficulty in getting the mobile market to accept their hardware has pretty much no bearing on whether or not they're a good choice for something like Pandora. For comparison, OMAP5 is still on the table, but I guarantee you'll see that in fewer phones and tablets than Intel's Silvermont-based SoCs.I thought some changes to the motherboard were needed when P1 went 1 GHz? I really was thinking about P2 upgradeability, not desktop PCs...
Anyway, like I have already said earlier, as long as the system works, I don't care about the ISA... and in fact, like I've pointed out in other threads, I'd be a heavy user of x86 instruction set via Wine, possibly DOSBox, etc.
But with Intel there is this one thing:
http://gigaom.com/2009/04/08/intel-going-mobile-with-moorestown-pushing-nehalem-everywhere/
This article got released about the time I originally ordered the Pandora. And where are those mobile products now, 4.5 years later?
I know, I know... This Time It's Different. Well, in a few weeks/months we'll see (again, only This Time It's Different...)...
Intel's continuing lack of capability to get this right has created a strange psychological barrier for me, I admit that. But it's nothing a good phone sized product would not wash away.
I don't wish them to fail, quite the contrary, all competition is good competition. It's just that... They're Intel, right? They have failed so many times, so won't they just fail again?
See what I mean?
That said, while you see continual failure I see them gradually improving to the point of being competitive and a market reaction that reflects this, possibly with a bit of a delay (as in, Moorestown and OakTrail got almost no products, while Medfield, CloverTrail, and CloverTrail+ showed up in at least some significant devices)
This is exactly the problem. Nothing about x86 is for desktops and nothing about ARM was for mobile. Don't you know that ARM was first deployed on desktops in the mid-80s? Most of the arguments of RISC vs CISC are much less relevant than they were 20+ years ago. They're just regurgitated without much interest in examining them critically. The architectural differences between x86 and ARM today play a very small role in efficiency when it comes to mobile processors. The disadvantage is there but it's much smaller than the disadvantage you get by being 1.5 nodes behind in manufacturing or not having the same level of experience with CPU design or layout.
In other words, it's wrong to think that Bay Trail is a processor designed for desktops just because it's x86. And it's wrong to believe that people were compelled to writing more optimized code for ARM just because it was weaker. By and large no one writes optimized code for anything, and the few that do write it as needed.
Look at actual benchmarks vs power consumption measurements and stop just repeating this dogma.
Last edited by a moderator:
I have nothing a priori against Bay Trail, but I need to see more information (on power consumption) before I can form an opinion. So far I've seen nothing more detailed than bullshit claims like "3W for web browsing, 2W for 1080p movie playback" which basically says nothing. That and Intel claiming it is very low-power.
God Ginrai
Godmaster
Before you toss the "stop repeating this dogma" line on me, you have yet to refute my arguments about the software. You should know better than anyone that code optimization does not immediately mean "write assembly". Also, I never said that ARM was a mobile device architecture, I said that it is traditionally used in gaming handhelds which is a completely true statement. You're talking about people being blinded to what x86 for mobile can do right now, yet you yourself have blinded yourself to my arguments.
-God Ginrai
Exophase
Nothing good will ever come of Exophase.
http://www.anandtech.com/show/7314/intel-baytrail-preview-intel-atom-z3770-tested/2
With one thread pegged @ 2.4GHz "SoC power" is 800mW to 1.2mW. With four threads pegged (and a scaling in performance that's nearly 4x) "SoC power" is around 2.5W. This was using Intel's measurement systems, but unless they're ignoring significant power rails there's probably not that much to cheat. It should be isolating power consumed by other things. This means that the per-core power consumption at peak is ~1W at most, but in reality could be ~0.5-0.6W which is phenomenal. It also does very well in all of the CPU benches, best in class. Anandtech doesn't show Geekbench, but they do well there too (maybe not quite as well but about the same as the fastest ARMs out).
Anandtech's writing is pretty slanted towards Intel and Apple, but I think it's hard to see this as anything that isn't competitive, and certainly makes the claims that it must have terrible efficiency because it's x86 look silly.
HotHardware had a flattering review as well:
http://hothardware.com/Reviews/Betting-On-Bay-Trail-Intels-Atom-Overhaul-Tested/?page=5
Intel's previous generation tablet SoC (CloverTrail) already had competitive perf/W (look for reviews, you can find all sorts of stuff because Intel shipped out power measurement kits to everyone to stress this point). BayTrail greatly improves on this. Although HotHardware's comparative numbers are mainly the web browsing and video playback variety, they also gave a number for a couple of games, showing that it consumed a similar about that CloverTrail did. Which is impressive when you consider that BayTrail has much, much stronger GPU performance.
You don't have arguments, you have unsubstantiated claims. The burden lies completely on you to actually provide some sliver of evidence for them. I'm not ignoring your mention that ARM has been used in gaming handhelds where x86 hasn't - I'm questioning its relevance. No x86 SoC was appropriate for a gaming handheld at any point when they were released in the past. Now they are. And no, you didn't say that ARM was designed mobile, but you contrasted it with the claim that x86 was designed for desktops. ARM was designed for desktops just as much as x86 was.
What I know about code optimization on a device like Pandora is that I can count the number of people on one or two hands who have really been serious about it. And yes, that goes beyond the "writing in assembly" part of optimization. But if it's not written with ARM assembly, and it's open source (most of the stuff running on Pandora now is), what's to stop it from being ported?
And there's stuff on both sides of this. Software-wise, some things are better optimized on x86 today. Look at JITs and compilers where those targeting ARM have spent years trying to catch up. It doesn't help that Intel throws a ton of resources at this.
Much of the software running on Pandoras was never "optimized" for Pandora but manages okay. Much of it was written targeting desktops. Much of the stuff that's held over from older ARM devices is emulators - and many of them have counterparts for PCs that's been optimized to a similar degree. I don't deny that there's you lose some software quality going away from ARM (I've said this myself before), that some of the effort is gone and some of it has to be redone. I know that very well. But that doesn't mean you can brush it in broad strokes of "ARM software fast, x86 software slow!" like you are. And don't say that you aren't, that's totally what you're doing.
Last edited by a moderator:
kuru
Who the heck is Stephan Kramer?
Please excuse me for plunging into this interesting discussion with this question.
Could we have the same level of quality, as in FPS, on the P1's emulators *without any optimization* using Baytrail or a near-future successor? That's about working N64 as 'bleeding edge' - which I personally don't use at all because of my nubs, but that's beside the point - and quasi-perfect PSX. Have yet tp use NDS and PSX, so not going there.
I can tell that the two things I ported won't give me any trouble recompiling for X86 and they'll run without optimization.
Could we have the same level of quality, as in FPS, on the P1's emulators *without any optimization* using Baytrail or a near-future successor? That's about working N64 as 'bleeding edge' - which I personally don't use at all because of my nubs, but that's beside the point - and quasi-perfect PSX. Have yet tp use NDS and PSX, so not going there.
I can tell that the two things I ported won't give me any trouble recompiling for X86 and they'll run without optimization.
Last edited by a moderator:
Exophase
Nothing good will ever come of Exophase.
It's at least partially moot - why? Because PCSX-R does have optimization for x86, because it has a recompiler targeting it. I don't know if Ari64's recompiler, used as a base in PCSX-reARMed, is used in its x86 build too (it does build on x86 Linux), but I do know he worked on the x86 side of the recompiler in parallel with the ARM side. The NEON renderer I wrote for PCSX-reARMed would not be available on x86. That's something someone (possibly me) would have to rewrite for it. Considering that a BayTrail CPU would have at least 4x the single-threaded performance as Pandora meeting that same baseline would be pretty easy even with not as advanced code.
On the flip side, a functional OpenGL renderer may be more possible, since there's some chance the chipset would actually support proper OpenGL.
Right now, PS1 GPU and DS (the two things I wrote
) are the only things emulation-related I can really think of where the level of hand-optimization is going to be missed. I have no doubt that the other emulators on Pandora done by notaz (PicoDrive, gpfce for example) and me (Temper, gpSP) are more efficient for ARM than x86, but we're talking about emulators that ran on GP2X - the difference is largely in the noise, even when it comes to battery life. Using 1/5th of one core's CPU time vs 1/10th barely makes a difference when you have to power the rest of the device. N64 in its current state is probably just as optimized for x86, as is PSP.
Last edited by a moderator:
kuru
Who the heck is Stephan Kramer?
sounds good to the uneducated me. And the rest of what you said, not too bad either.
Last edited by a moderator:
God Ginrai
Godmaster
Generally when you code something, and it doesn't run at good speeds, you normally try to optimize your code. On x86 laptops and desktops, you don't notice the speeds because you normally aren't limited, on ARM you do notice it, because it is much less powerful than an x86 desktop. I seriously doubt that you can count on two hands everyone who has tried to make their software run faster on the Pandora. Not intensely faster, but even just small tweaks.
Oh, I'm certainly saying "ARM software fast, generally, x86 software slower, generally!". But that's because it is a valid point. It's not the only point to be made, but it shouldn't be dismissed, either.
-God Ginrai
Exophase
Nothing good will ever come of Exophase.
It'd be great if this is how it works. How do you know how many times people really optimize something regardless of how much it's needed? Plenty of people who port things don't get involved beyond that...
If we're just talking small tweaks then why are you so concerned that people won't make these small tweaks for an x86-using Pandora 2? It's new work, it's a disadvantage, but it's not some intrinsic thing that you're stuck with forever.
But without actually evaluating the impact in any kind of quantitative way what are you supposed to draw from this? It's just conjecture. I mean, I can just as easily balance it with a claim that a lot of software that's interesting to port today was written when x86-based computers were slower than BayTrail is today, and - going by your claims of optimization as a function of necessity - would already be "sufficiently" optimized.
Last edited by a moderator:
God Ginrai
Godmaster
Yes, but having already optimized code shortens the process for the users to get a large number of applications.
Yes, but the majority (not all, but the majority) of optimized ARM applications have also had important UI tweaks that will better fit them on a mobile device. On x86, this would not be the case, since x86 has not had much hold in the mobile space until now.
-God Ginrai
- Joined
- Jan 18, 2010
- Messages
- 11,418
Well then it's still up to a dev to make UI and control updates. Also I gather the PND system or something like it would still need to be implemented if we want removable SD cards. So that end of things would still need developer intervention.. If people want to just run windows (willing that this device could just boot it) then people will have to face facts they may run into resolution, screen size issues and other stuff that makes a less optimal user experience.
But I'm still pushing for ARM myself.. Go ARM!
Last edited by a moderator:
God Ginrai
Godmaster
Yes, but my point is that that is more work. (and more time wasted doing such work) If good GUIs were that easy to make, all our emulators would have PicoDrive's GUI by now.
-God Ginrai
Exophase
Nothing good will ever come of Exophase.
Okay, so I'm going to go back to what I said earlier - most software on Pandora is open source, and most of the optimization work you're talking about isn't down to arch-specific stuff.
The tangible setbacks here are not getting the benefit from hand-optimized ARM code and missing a few closed source options entirely. Those hand-optimized ARM examples are the ones I can count on a couple hands. A lot of it isn't really that critical for Pandora 2. The remaining stuff is a real issue, but just getting the dedication of a small number of people would make a big difference. The loss of closed source stuff is real but you also gain closed source stuff with x86 (I agree with Grench that Steam on x86 could be significant).
Now, any problem of this nature could persist going forward. If you have people who were willing to do ARM-specific optimization now not willing to do x86-specific optimization - in the few instances where anyone was willing to do this sort of optimization to begin with - that's a loss. And if you have devs who won't support the thing at all because it's x86, that's a loss too (if notaz drops out that could be a serious deal breaker). But these aren't really technical arguments, they're more political or personal ones, and the thing is that right now we don't know what people will do. I'm just hoping that both users and developers can make the most objective and informed decisions on this as possible. While I could see ARM winning at all costs because of an extreme cultural bias towards ARM I hope this isn't why it happens, and really, the people who support this outcome should hope for this too.
Again - why would any of this not be portable to an x86-based platform? Most Android stuff already runs on x86. Most Pandora stuff is open source and portable to x86 (although that doesn't stop a lot of them from using desktop-like interfaces). I'm really not seeing how this is a problem tied to architecture.
Last edited by a moderator:
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
So - you think that any ARM CPU, regardless of technology, availability, driver support, performance per watt is favorable regardless of competition?
No room for rational reason, facts, options or alternatives.
But these go up to 11...
http://en.wikipedia.org/wiki/Up_to_eleven
It still amazes me how fast the conversation here went from, 'Hey, check out these new Z3770 CPUs from Intel - they're kind of neat.' to, 'OMG all the developers are going to run away!'
Sky is falling. Hell froze over. Newts are falling from the sky. Intel created an X86 command set processor that may be more open and may have a better performance per watt profile and better driver support than existing ARM alternatives.
Can we return to rational considerations?
[citation needed]
People seem to disagree on this one....
What proportion of popular Android software actually uses ARM-specific code (and doesn't have an x86 version hiding around the corner)?
Last edited by a moderator:
Similar threads
