Intel Atom vs ARM
|
Prev: NTP: (Was: Re: performance of hardware dynamic scheduling)
Next: A race-condition in a SUN paper by Detlefs on reference counting...
From: already5chosen on 6 Apr 2008 10:19 On Apr 5, 2:35 pm, Thomas Womack <twom...(a)chiark.greenend.org.uk> wrote: > In article <ft60ki$gm...(a)gwaiyur.mb-net.net>, > Elcaro Nosille <Elcaro.Nosi...(a)googlemail.com> wrote: > > >Elcaro Nosille schrieb: > > >> I just asked myself what the prices of the Atoms > >> might be. Has anyone concrete information on that? > > >I googled and found this prices: > > > Z500 800MHz 0.65W 400 MHz $45 > > Z510 1.10GHz 2.00W 400 MHz $45 > > Z520 1.33GHz 2.00W 533 MHz $65 > > Z530 1.60GHz 2.00W 533 MHz $95 > > Z540 1.86GHz 2.49W 533 MHz $160 > > I tend to expect embedded processors to have really good > price/performance ratios, at the price of being too small to fit the > jobs I'm interested in on them. Atom is at least big enough. > > But Atom is the other way round: 1% of the power consumption of a > Q6600, about 10% of the performance, and about 17% of the price. Much worse than that when you look at system level. For example, Atom's Poulsbo chipset power consumption is close to 5% of X38 which is a highest performing chipset for Q6600. The price for cheapest Atom subnotebook (Asus eeePC) would be above $300, i.e. 30-50% of solid X35-based Q6600 desktop. Of course it's not strictly apple2apple comparison because on one hand with eeePC you get LCD while on the other hand with desktop you get HD+DVD but no display. > > Is there anything which has a price-per-gigaop ratio as good as a > Q6600? (say 40 peak-gigaops for $266 + $200 in motherboard and RAM). > > Tom Well, amongst Intel chips - Q9300 that should be available en masses around June. Or X3320 (UP Xeon) which is available now. But the difference in GFlops/$ is rather small and the cache is smaller than Q6600. If you don't need cache you could try lowest-end parts - E2220. On Amd side Phenom 9850, Phenom 9750 and all Athlon X2 parts except two top bins. X2 parts are interesting only if your code is purely scalar. If you are doing SIMD - ignore them.
From: already5chosen on 6 Apr 2008 10:24 On Apr 4, 9:47 pm, Elcaro Nosille <Elcaro.Nosi...(a)googlemail.com> wrote: > Elcaro Nosille schrieb: > > > I just asked myself what the prices of the Atoms > > might be. Has anyone concrete information on that? > > I googled and found this prices: > > Z500 800MHz 0.65W 400 MHz $45 > Z510 1.10GHz 2.00W 400 MHz $45 > Z520 1.33GHz 2.00W 533 MHz $65 > Z530 1.60GHz 2.00W 533 MHz $95 > Z540 1.86GHz 2.49W 533 MHz $160 > > I think these are too expensive for most embedded devices. The latest price list contains cheaper price tags: http://media.corporate-ir.net/media_files/irol/10/101302/price_sheet4_2.pdf But it doesn't change the conclusion - both too expensive and not sufficiently integrated. If Intel is interested in pushing embedded PC for broader range of applications they should forget about Atom and release Tolapai ASAP, The damn thing is already like one year late and is still not available.
From: Wilco Dijkstra on 7 Apr 2008 06:40 "Nick Maclaren" <nmm1(a)cus.cam.ac.uk> wrote in message news:fta9v9$c5u$1(a)gemini.csx.cam.ac.uk... > > In article <nE1Kj.26532$Re3.2093(a)newsfe4-gui.ntli.net>, > "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)ntlworld.com> writes: > |> > |> Any non-trivial piece of C code will only work on one endian unless it > |> was specifically designed to work in both (having done that at various > |> levels I know how much work this really is). > > Having done it myself, several times, I am quite certain that you were > doing it wrong, if that is your experience. It is almost trivial to do, > if you do it right. One of my codes supported even mixed-endian, of an > almost arbitrary order. Sure just adding a macro here and there is easy, but that only addresses one of the many different issues. Most people don't even know that there is an endian invariant size or that structures can have different sizes in little/big endian... I'm talking about efficiently supporting all combinations of host and target endian, endian invariant sizes, different endian for code and data, multiple different data layouts of long long, double, bitfields, interfacing with assembler libraries etc. Just testing the crossproduct of options causes many people a headache... > |> Embedded code is often low > |> level to be as efficient as possible, and typically relies on a particular > |> structure layout, direct access to hardware or nasty pointer tricks. > > Nowadays, code and workspace size is not particularly tight (we are > talking about only a few hundred words, after all), and it is very > rare code that spends most of its time encoding and decoding network > packets. Routers, IP filters are similar are perhaps the only code > where such tricks are likely to be essential. Actually most embedded systems do these tricks. Embedded systems are small, have limited code/data memory, and need to keep their power consumption low. So people usually code at a very low level (no OS or just a basic RTOS, Linux is only used in high-end devices), and time consuming tasks need to be highly optimised. At 10-100 million units a year even a tiny saving can make a big difference. Wilco
From: Nick Maclaren on 7 Apr 2008 06:52 In article <6SmKj.373$2v.223(a)newsfe4-gui.ntli.net>, "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)ntlworld.com> writes: |> |> > |> Any non-trivial piece of C code will only work on one endian unless it |> > |> was specifically designed to work in both (having done that at various |> > |> levels I know how much work this really is). |> > |> > Having done it myself, several times, I am quite certain that you were |> > doing it wrong, if that is your experience. It is almost trivial to do, |> > if you do it right. One of my codes supported even mixed-endian, of an |> > almost arbitrary order. |> |> Sure just adding a macro here and there is easy, but that only addresses |> one of the many different issues. Most people don't even know that there |> is an endian invariant size or that structures can have different sizes |> in little/big endian... "Adding a macro here and there" is precisely what I meant by doing it wrong. And, no, endianness does not change the sizes of anything - but genuinely portable code can handle size, endian and other differences. |> I'm talking about efficiently supporting all combinations of host and |> target endian, endian invariant sizes, different endian for code and |> data, multiple different data layouts of long long, double, bitfields, |> interfacing with assembler libraries etc. So? Look, I wrote code in the days when we had to handle word sizes that weren't powers of two, systems that weren't twos' complement, and so on. I can assure you that handling what you describe isn't even tricky - IF it is done right! And the first rule of doing it right is to get all of that system- dependent crud out the main code, and localise the translations into and out of a common, portable, clean working format. I.e. precisely the CONVERSE of C99. |> Just testing the crossproduct of options causes many people a headache... Then don't do that. It's the wrong way to do it, anyway. Regards, Nick Maclaren.
From: Wilco Dijkstra on 7 Apr 2008 08:51
"Nick Maclaren" <nmm1(a)cus.cam.ac.uk> wrote in message news:ftcudb$lkv$1(a)gemini.csx.cam.ac.uk... > > In article <6SmKj.373$2v.223(a)newsfe4-gui.ntli.net>, > "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)ntlworld.com> writes: > |> > |> > |> Any non-trivial piece of C code will only work on one endian unless it > |> > |> was specifically designed to work in both (having done that at various > |> > |> levels I know how much work this really is). > |> > > |> > Having done it myself, several times, I am quite certain that you were > |> > doing it wrong, if that is your experience. It is almost trivial to do, > |> > if you do it right. One of my codes supported even mixed-endian, of an > |> > almost arbitrary order. > |> > |> Sure just adding a macro here and there is easy, but that only addresses > |> one of the many different issues. Most people don't even know that there > |> is an endian invariant size or that structures can have different sizes > |> in little/big endian... > > "Adding a macro here and there" is precisely what I meant by doing it > wrong. And, no, endianness does not change the sizes of anything - but > genuinely portable code can handle size, endian and other differences. Changing endian does change structure size, this is exactly the kind of thing that catches the less experienced people :-) > |> I'm talking about efficiently supporting all combinations of host and > |> target endian, endian invariant sizes, different endian for code and > |> data, multiple different data layouts of long long, double, bitfields, > |> interfacing with assembler libraries etc. > > So? Look, I wrote code in the days when we had to handle word sizes > that weren't powers of two, systems that weren't twos' complement, and > so on. I can assure you that handling what you describe isn't even > tricky - IF it is done right! > > And the first rule of doing it right is to get all of that system- > dependent crud out the main code, and localise the translations into > and out of a common, portable, clean working format. I.e. precisely > the CONVERSE of C99. That's certainly possible but usually infeasible if you need efficiency (and it's way overkill if you need to do something simple anyway). You usually want to work using the host endian and only swap input/output data when absolutely required. C99 doesn't come into it, people were mapping C structures onto hardware and file formats since the early days of C. And it works if you know what you are doing... > |> Just testing the crossproduct of options causes many people a headache... > > Then don't do that. It's the wrong way to do it, anyway. So explain how you would test multiple orthogonal choices that have complex interactions with each other without testing most of the cross product. Wilco |