TDP is supposed to be a maximum allowed dissipation - with that in mind, you can see that the only thing that could vary this is clock speed. Indeed, Intel claims that it's the 500MHz version that can get 0.6W.Chip said:
Exophase said:The question is if they'll be competitive with ARM in power/performance ratios, and at this point I'm strongly doubting it.
I am ready to bet they won't be able to achieve that within two years.
QUOTE
If Intel can halve the power consumption without compromising performance in any way whatsoever then I'd love to know what they're doing, and why they're even bothering rolling out Atom as it is now at all.
Indeed. Atom looks like a complete architectural mistake. Going in-order was utterly stupid. I can only guess they did that because they didn't how to reduce power. However I am sure they are able to beat ARM, but it certainly won't happen within two years.
You want real data? Atom @1.6 GHz is about the speed to P3-M @1.13 GHz and 20% slower than current Celeron-M @900 Mhz.Exophase said:
Granted, it's only some Super PI stuff, but anyway that proves my point regarding in-order shit
Ref: http://xtreview.com/addcomment-id-4447-vie...-benchmark.html
Exophase said:Laurent; All the negative in-order sentiments makes me worried about some things on A8, especially generated code (recompilers). However, I do think that having significantly more registers for most things that will be ran (ie, I don't think that people will be running 64bit apps on Atom all the time) helps lessen the pain of in-order, allowing the compiler to rename more registers in software.
I really hope GCC can schedule for Cortex-A8 okay.
As far as recompilers are concerned, you will have to schedule by hand. But did you have to do that for the GP2X ARM9?
For gcc, the back-end has been available for months and it's open-source, so it's up to you to make it better if you feel the need
QUOTE
It's kind of disillusioning that ARM was defending their choice for in-order for A8 so heavily (albeit, purely from a power consumption point of view), then rolled out A9 which went for out-of-order and a smaller pipeline.
Though I can't comment too much on that as you guess, keep one thing in mind: a processor takes several years from early design decisions before it comes in your hand. Now project yourself back, let's say 4 or 5 years back. Do you think there were many out-of-order chips in the low-power embedded market? Did the UMPC concept even exist at that time? What CPU power did PDA and smartphones need? The market has evolved, ARM has moved forward, but Intel has stepped back.
QUOTE
EDIT: Important question that I think is relevant to determining Atom's performance - why is a 1.13GHz Tualatin performing so much worse a 900MHz Celeron-M in Super-PI? The architectural differences shouldn't be that ground breaking, and the only major differences I can think of that would contribute this much are memory bandwidth and SSE2. If it's using an SSE2 version vs a SISD one for non-SSE2 then we can throw the Tualatin score out altogether (and any tests involving Cortex-A8/A9, since it doesn't have double precision SIMD either.. which is all but irrelevant for just about anything anyone would want to use it for on a handheld)
SuperPI doesn't use SSE2. I was told it uses x87, so it naturally stinks
The only comparison Intel did, was Atom vs OMAP2420 browsing performance. And you know what? They did that with no network connection, pages were locally stored. And comparison against a 2 or 3 years old chip. Pure marketing bullshit.
Exophase said:TDP is supposed to be a maximum allowed dissipation - with that in mind, you can see that the only thing that could vary this is clock speed. Indeed, Intel claims that it's the 500MHz version that can get 0.6W.Chip said:
Now, the thing is, Intel is being very careful with their wording because there's no question that this CPU will perform worse, clock for clock, than any x86 CPU Intel has released in several years. They say that the single threaded performance is equivalent to an original Pentium-M, but they don't mention clock speeds. I wouldn't be at all surprised if they were comparing a 900MHz one to a 1.8GHz Atom. Or, if compared with the A100, it'd be a 600Mhz CPU against, again, something as high as 1.8GHz. If either are the case then a 500MHz Atom doesn't sound that great at all.
Sure, these will be viable for handhelds, if that's what people want to use. The question is if they'll be competitive with ARM in power/performance ratios, and at this point I'm strongly doubting it. If Intel can halve the power consumption without compromising performance in any way whatsoever then I'd love to know what they're doing, and why they're even bothering rolling out Atom as it is now at all.
EDIT: Finally found the relevant comparison: "The 2 GHz variant of the Silverthorne processor will operate at 1 volt and it will have performance equivalent to a first generation “Banias” Pentium M notebook processors circa 2003. " (http://blogs.zdnet.com/Ou/?p=987) - unfortunately this helps little, because 2003 saw the release of 900MHz to 1.7GHz Pentium-M's. Even if you restrict it to the very first batch they still went all the way up to 1.6GHz. But I think giving MHz for the Atom and not the Pentium-M is pretty telling.
Well see this youtube video : http://youtube.com/watch?v=rWFkRUOFVmM
Intel guy was asked about performance of atom and he said "half of celeron" which I assume means "half of celeron of the same clock". But well not sure which Celeron he was referring to since there have Celerons of so many generations
In any case most of this discussion is theoretical at this point. In this industry never believe what the hardware vendors tell you until some independent performance tests comes out. Wait for a couple of months till the Atom based systems come out : the new EEE and the much hyped MIDs. Once we get some independent reviews of its performance, battery life and once we get the idea of the price of devices, then we will know better. Right now all that we have is some info and PR videos fed to us by Intel.
The same goes for the Cortex A8 and A9. ARM claims good numbers but we dont have a device in our hands. At max what people have are dev boards till now. In the comments on the article on the beyond3d site, you will also notice strong displeasure with the Cortex A8. And the A9 hasnt appeared in any real devices either. In most cases we only have numbers like "web page rendering" and Dhrystone MIPS neither of which can easily map to a real world workload for a device like the Pandora for example.
Finally only technology has never been a deciding factor in the industry either. We cannot say what the big software vendors will do in the future or what kind of devices will people want. Maybe people simply dont want those MIDs or whatever and only want a smartphone in which case there simply isnt a big enough market for Intel. Or take the EEE. Sure the EEE has sold about half a million (correct?) units but how many more will people buy? Maybe 1 million? 10 million? 50 million? No one knows that either. If these categories dont take off then I doubt Intel will put a lot of money behind the Atom.
I had to ponder on this comment for a bit...A question or two, if I may...Laurent said:
I'd hesitate to call it pure marketing bullshit. Peak performance for rendering HTML would be from static content on the local disk. All you're doing with a network connection is testing networking performance and storage performance (because it's typically dumped to RAM or "disk" locally FIRST before rendering it..).Laurent said:
)Svartalf said:
I don't know the answer to that question- however, the amount of memory really comes relevant when you start considering size of the content. Pocket IE ARM is actually going to perform similarly to MiniMo on a Nokia N8x0 machine or on an eeePC if built for it for similar load situations.randomhack said:
Svartalf said:
There's no way I'm diving into gcc whether it needs it or not, I'd much sooner write my own ASM. I don't schedule for ARM9 in my recompiler (it's really not that sophisticated, and you'll be very hard pressed to find a recompiler that is), but there's much less to actually schedule for than on Cortex. Loads would usually be naturally surrounded by other instructions anyway.Laurent said:
Maybe I noticed Cortex-A8 a little late (afterall, it hasn't even been a commercial option at all until what, last year? Maybe 2006?) but it hardly seems to be 4 or 5 years old, and A9 does seem to be coming on its heels. The minor number change follows this, despite it being a major architectural revision. I think that A8 was probably a transitional chip and will never really be used nearly as much as ARM11 or Cortex-A9 will be unless OMAP3xxx catches on heavily.Laurent said:
I didn't see any "strong displeasure" towards Cortex-A8 at all, merely indications that A9 is a certain percentage faster than it. That is completely to be expected for an entirely new generation CPU core. I can't see why anyone would be critical of A8 when it's a major move forward over ARM11 while still being quite low power, as opposed to Silverthorne which looks more like something Via would roll out (ironically, Via's Messiah actually looks like a better chip). There are more benchmarks than that, Dhrystone DOES mean something (remember, we're testing CPUs here, not the memory subsystem), and we've even seen numbers for Pandora (although probably nowhere near what it'll be like when we have final revisions of hardware and more optimized code)randomhack said:
x86 and ARM are not architectures, they are instruction sets. If indeed you do mean to talk and instruction sets then please qualify why you think there are other RISC ISAs that are far superior to ARM. And no offense, but please do it with actual reasons and not just by saying how many years you've programmed in such and such for so and so. I'm getting kind of tired of that general line of argument from people.Svartalf said:
What inaccuracies? If you're going to say that please clarify. This is coming from someone who himself admitted to not understand the technology involved, right?Chip said:
Now THAT'S speculation.Chip said:
If it will make you happy...Exophase said:
Exophase said:
Read the bottom of the article, it's amended to clarify that he's talking about all of Intel's slated low power chips thus far announced.Chip said:
Do you know anyone who has a Silverthorne for testing? He's comparing Intel's claims with ARM's (you don't think ARM doesn't have working reference silicon, I hope). More importantly, he's illustrating the flaw in Intel comparing Silverthorne with a CPU announced 6 years ago. Just one of Intel's many marketing tricks which they'll use to try to overtake the mobile sector.Chip said:
Chip said:
Chip said:Intel and ARM themselves don't know how Moorestown and A9 will compare because neither of them actually exist yet.
I can state that at least half of this statement is wrong
I don't know yet if I will get a Pandora or not. What I am sure is that if I would get one, it would be to play at assembly level, both on the ARM core and the c64x. I have various projects in mind. Too bad craigix found no time to answer my e-mailSvartalf said:
Svartalf said:I'd hesitate to call it pure marketing bullshit. Peak performance for rendering HTML would be from static content on the local disk. All you're doing with a network connection is testing networking performance and storage performance (because it's typically dumped to RAM or "disk" locally FIRST before rendering it..).Laurent said:
I disagree (surprise
I have been playing with standard benchmarks (from dhrystone up to spec2k) and I can tell you it's easy to double or halve the speed even for spec2k depending on the OS conditions (and no I am not talking about a loaded OS, I am just talking about funny effects of TLB).
It's like the PC world: do you really look at synthetic benchmarks when you build your PC? Or do you look at the speed of the type of games or applications you will use?
So when I am presented with the Intel slide about browser performance, I call it pure bullshit (also note others on this thread have already told how bad this slide is due to lack of real information about the conditions).
QUOTE
Is x86 great? No. Is ARM great? Not really, either. There's, by far, better architectures in the RISC camp. And... Before you get on about me not knowing much about it- I've programmed professionally on the following:
x86
x86_64 (Yes, it IS different...
ARM
MIPS
Sparc
Power4
In either desktop, server, or embedded contexts.
So I have more experience than you
I seriously hate x86(_64) ISA, any RISC is so much funnier to program
As far as RISC ISA's are concerned, MIPS is the cleanest one, though I don't know what it has become, I have not used it since 10 years.
ARM architecture has nothing to do with implementation of it. The ARM architecture describes : an ISA, a system coprocessor, a memory model. At least that's the way ARM talks. For instance, Cortex-A8 is an implementation of ARMv7-A architecture.Exophase said:There's no way I'm diving into gcc whether it needs it or not, I'd much sooner write my own ASM. I don't schedule for ARM9 in my recompiler (it's really not that sophisticated, and you'll be very hard pressed to find a recompiler that is), but there's much less to actually schedule for than on Cortex. Loads would usually be naturally surrounded by other instructions anyway.
Scheduling wouln't only affect loads and stores. And C-A8 support in gcc is located in a few files. The scheduler description is not that hard to read
QUOTE
Maybe I noticed Cortex-A8 a little late (afterall, it hasn't even been a commercial option at all until what, last year? Maybe 2006?) but it hardly seems to be 4 or 5 years old, and A9 does seem to be coming on its heels.
The 4 or 5 years was from design start to market.
QUOTE
There are more benchmarks than that, Dhrystone DOES mean something (remember, we're testing CPUs here, not the memory subsystem), and we've even seen numbers for Pandora (although probably nowhere near what it'll be like when we have final revisions of hardware and more optimized code)
Dhrystone is the worst of the currently industry quoted benchmarks. It certainly doesn't mean anything, trust me. For instance, its rules forbid inlining, because if you inline stuff, you can propagate so many constants that it runs incredibly fast. You also can't compile the two files in a single compilation, because again information propagation would kill it. Now is that representative of how developers work? And is your code spending most of its time doing memcpy and strcmp?
QUOTE
x86 and ARM are not architectures, they are instruction sets. If indeed you do mean to talk and instruction sets then please qualify why you think there are other RISC ISAs that are far superior to ARM. And no offense, but please do it with actual reasons and not just by saying how many years you've programmed in such and such for so and so. I'm getting kind of tired of that general line of argument from people.
For the record, pretty much everyone I've ever talked to who has programmed in multiple ISAs thinks that ARM is the most elegant they have used. I'm familiar with all of the instruction sets you've listed and I can't think of any of them that offers conditional execution, folded barrel shifting, optional flag setting, PC as a register, and the flexible addressing modes ARM does (I don't mean none of them offer any of this, but none to the degree ARM does). There are benefits, but they're mainly limited to more registers or lack of flags. MIPS and SPARC in particular are pretty bottom of the barrel when it comes to power per opcode.
EDIT: Since I figure someone's gonna say it, yes I know ISA stands for "instruction set architecture." But usually when people say architecture they mean a particular CPU design.
What would scheduling affect besides loads? I don't know of any other important case where the ordering of the instructions can add stalls on ARM9.Laurent said:
Maybe for someone who is experienced hacking GCC. Again, there's no way I'd be diving into it for something like this. Obviously you know what you're doing with it.Laurent said:And C-A8 support in gcc is located in a few files. The scheduler description is not that hard to read
If that's the case then either A9 was being developed concurrently with A8 or it took much, much less time to develop. It's not as if out of order was invented 5 years ago, and for that matter Silverthorne is being released hardly any later than A8 is being adopted, so the same argument could apply to both (except there was no superscalar ARM before this, and x86 has been superscalar for over a decade)Laurent said:
I'm not really getting how any of this means that it means nothing, it just means that it has to be compiled a certain way, although I suppose lack of certain optimizations will forces the compilation used down to something unpleasant. I still think the numbers have shown something in terms of relative performance, even if the test is flawed.Laurent said:Dhrystone is the worst of the currently industry quoted benchmarks. It certainly doesn't mean anything, trust me. For instance, its rules forbid inlining, because if you inline stuff, you can propagate so many constants that it runs incredibly fast. You also can't compile the two files in a single compilation, because again information propagation would kill it. Now is that representative of how developers work? And is your code spending most of its time doing memcpy and strcmp?
I don't know how ARM defines architecture, but this isn't just about ARM. I've never heard of anyone refer to x86, the ISA, as an architecture. I'm going to assume ISAs are what were being referred to anyway. I do believe that "architecture" has connotations of physical design (like a building being made) rather than a more general language and model. I take it you call ARM9, ARM11, etc "implementations" then? Or does ARM have a more suitable term?Laurent said:
When I say elegant I mean for the PROGRAMMER, not someone designing a CPU that uses it. For someone citing years of experience programming it and not designing CPUs that utilize it I can only think that's what he meant, and for the many more people that program it than design CPUs around it I can only guess that's what's going to be the relevant factor (even if far less people use ASM now).Laurent said:
