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: Terje Mathisen on 5 Apr 2008 07:28 Elcaro Nosille wrote: > Paul Gotch schrieb: > >> No because routers/network equipment want big endian data >> for efficently handling IP packets which is why a hell of >> a lot of them are MIPS or PowerPC since ARM only recently >> got a byte invariant big endian mode. Now it has one you >> are starting to see ARMs tip up in some neworking equipment. > > Do you really think that a BSWAP per word would make a > noteworthy overall performance-difference in IP-handling? No, it wouldn't. Besides, using SSE you could byteswap up to 16 bytes in a single cycle, right? Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: Benny Amorsen on 5 Apr 2008 08:00 "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)ntlworld.com> writes: > It depends on the kind of router, if it is a high end one the overhead > might well be noticeable. If it is a high end router it is using ASIC's anyway. /Benny
From: Thomas Womack on 5 Apr 2008 08:35 In article <ft60ki$gmo$1(a)gwaiyur.mb-net.net>, Elcaro Nosille <Elcaro.Nosille(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. 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
From: Wilco Dijkstra on 6 Apr 2008 06:31 "Elcaro Nosille" <Elcaro.Nosille(a)googlemail.com> wrote in message news:fta2ma$997$1(a)worf.visyn.net... > Wilco Dijkstra schrieb: > >>> No one would implement his own IP-stack as there >>> are well-established and solid implementations. > >> Exactly. And not all of this software is x86 based. > > It is written in C - for big and little-endia machines. 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). 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. Wilco
From: Nick Maclaren on 6 Apr 2008 06:51
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. |> 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. Regards, Nick Maclaren. |