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: Wilco Dijkstra on 18 Apr 2008 16:59 "Andrew Reilly" <andrew-newspost(a)areilly.bpc-users.org> wrote in message news:668tnbF2jp9v7U1(a)mid.individual.net... > On Fri, 11 Apr 2008 10:10:05 +0000, Wilco Dijkstra wrote: > >> For applications using a lot of data (thus cache misses) I'd still >> expect the usual bitfield packing to come out fastest. > > Are there many such applications? All of the applications that I know of > that use lots of individual boolean values, (usually some variation on > bitmaps or compressed file/bitstream formats) use explicit shifts and > masks on whole-word or whole-byte arrays. Compressed data and sparse bitvectors are common too but those are different data types altogether. > I've really never seen bitfield structs used the way you're suggesting, > but that clearly just means that I've been looking at a different set of > examples. I'm interested to know where this is being used (and what > degree of portability you're getting/expecting.) I wouldn't even expect > useful binary-file-mapping portability between toolchains on the same > processor, let alone across different processors with different > endianness or word size. Bitfields are used a lot in the embedded space, primarily to reduce data size. In 10 years I saw few embedded application that didn't use bitfields (the ones that didn't, used explicit masking (like p->status & B_READY) to pack bits. Performance is usually secondary, but a smaller working set improves performance on simple cores with small caches. In the desktop world, one application I know that heavily uses bitfields is a compiler. Saving space and improving performance are equally important here. For example an intermediate instruction can have lots of properties, and using the 32-bit booleans x86 compilers provide can blow up memory usage by a large factor. Setting and testing a boolean bitfield has very little performance penalty, so it's a no-brainer. Bitfields are perfectly portable if you don't rely on some of the weirder features (enum bitfields are not well supported for example). Bitfields are rarely used to get a portable data layout, however it is feasible if you use a subset of the features. Wilco
From: Wilco Dijkstra on 18 Apr 2008 17:31 "Nick Maclaren" <nmm1(a)cus.cam.ac.uk> wrote in message news:ftnf44$r9q$1(a)gemini.csx.cam.ac.uk... > > In article <1OGLj.39218$h65.32610(a)newsfe2-gui.ntli.net>, > "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)ntlworld.com> writes: > |> "Terje Mathisen" <terje.mathisen(a)hda.hydro.com> wrote > |> in message news:gJudnT7nquRiM2DanZ2dnUVZ8qqlnZ2d(a)giganews.com... > |> > |> > Matching/mapping a file format against a C bitfield is non-portable. > |> > |> Not if you use a subset of bitfield features. You can design a portable layout > |> just like you can for normal fields. Although there is an infinite number of > |> choices for the layout of structures, compiler writers typically choose the > |> most obvious way. > > There are many "most obvious" ways, and many of us have seen a great > many of them. For example, should bit-fields be left or right aligned > if they don't fill a 'word'? And are 'words' chosen for time or space > efficiency? And are bit-fields of different base types put into the > same 'word' or not? There aren't that many ways actually once you discount randomly reordering fields (not easily done since the order must be the same across files). To answer your questions: one should not leave any unused bits, so there is no choice. The bitfield container chosen is the type you used (I've never seen a compiler that didn't do it differently, just like no sane compiler write would allocate an 'int' field when you wrote 'char'). To avoid the issue of overlapping containers, start a bitfield at an offset that is a multiple of the container alignment and use up all bits explicitly. Using these simple rules you're left with 2 reasonable choices: filling from least or most significant bits. If you want to support little and big endian you need both. Since not all compilers support both choices, you can use a macro to do the swapping, eg. BITFIELD3(uint8, x:3, y:2, z:3); - not pretty but it works. > Please provide references for your claims that there is only one > correct answer, such as paragraphs within the C standard. Quoting anything from the C standard would contribute exactly... nothing. The C standard is pretty abysmal in specifying bitfields (mind you it does a lousy job at most of C...). In contrast, I designed a proper specification of (bit)fields that is used in various compilers. It's generic in that it can handle any type with any size or alignment, all of the bitfield features, and could easily accomodate additional packing choices if required. However I guess it's far too concrete and unambiguous to be interesting to the standards committee... Wilco
From: Wilco Dijkstra on 18 Apr 2008 17:33 "Nick Maclaren" <nmm1(a)cus.cam.ac.uk> wrote in message news:ftohkt$rf5$1(a)gemini.csx.cam.ac.uk... > > In article <ftqdndrS-YhKW2LanZ2dnUVZ8radnZ2d(a)giganews.com>, > Terje Mathisen <terje.mathisen(a)hda.hydro.com> writes: > |> Wilco Dijkstra wrote: > |> > |> > If you want to truncate stores only you also need to do any sign extension > |> > that you normally do on bitfield loads. The alternative is to just store the > |> > value and do the extract on all bitfield loads (worse if you have more reads > |> > than writes). > |> > |> This is a valid point, although I have _never_ used a signed bitfield. That's odd as bitfields are signed by default on x86. VC++ even refuses to use unsigned bitfields in some cases... I did file a few bug reports on enum bitfields a long time ago, not sure whether it ever got fixed. > I have spent some hours trying to work out what the C90 and C99 > standards specify about them, if anything, and ended up more baffled > than when I started. I know that some members of SC22WG14 think > that they are well defined, some others think they are undefined, > and some others think that they don't need defining because signed > bit-fields are obviously insane, but that doesn't help. They thought it was as insane as signed integers, or more so? > Given the inventive way that SC22WG14 interpreted C90 to deny > that C90 specified that 'long' was the longest signed integer type, > and that making the setting of 'errno' optional in <math.h> was > not a Quiet Change, God alone knows how C201x would interpret the > thoroughly unclear bit-field wording in C90 and C99. Ah, we at least can agree on that! Wilco
From: Wilco Dijkstra on 18 Apr 2008 17:42 "Nick Maclaren" <nmm1(a)cus.cam.ac.uk> wrote in message news:ft50qb$jo3$1(a)gemini.csx.cam.ac.uk... > > In article <mwnJj.7461$h65.2793(a)newsfe2-gui.ntli.net>, > "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)ntlworld.com> writes: > |> "Jon Harrop" <jon(a)ffconsultancy.com> wrote in message news:M76dnT7jTNiCnGvanZ2dnUVZ8v6dnZ2d(a)plusnet... > |> > > |> > In the light of recent discussions, I thought this article would be of > |> > interest: > |> > > |> > http://www.linuxdevices.com/news/NS5492118276.html > |> > |> See also: http://laptoping.com/intel-atom-benchmark.html which > |> shows Atom/Silverthorne is less than half the speed of a Celeron-M... > > It's unclear whether SuperPI measures anything of interest to the > potential market of such CPUs! It would definitely be interesting > to see appropriate comparisons, especially if they included ARM > systems. Although they may not be interesting for the target market either, this link mentions some specint2000 results: http://www.realworldtech.com/forums/index.cfm?action=detail&id=89505&threadid=89138&roomid=2 653 Specint2000 and 582 SpecFP2000 at 1.6GHz is pretty slow - no wonder Atom benchmark scores are so hard to find! Wilco
From: Wilco Dijkstra on 18 Apr 2008 17:55
<already5chosen(a)yahoo.com> wrote in message news:71d38e5e-fc00-4579-bc19-742decd62281(a)p25g2000pri.googlegroups.com... > On Apr 9, 1:38 pm, "Wilco Dijkstra" <Wilco_dot_Dijks...(a)ntlworld.com> > wrote: > >> Bitfields may be used to match a particular file format, or to reduce memory usage. > > In non-portable code, that is. In the portable code - only for later. > >>Additionally, >> when you write a value into a bitfield, it is truncated to the bitsize of the >> field, so you'd need to prove no truncation ever happens, or you can't >> reduce the overhead. > > Even for loads a single AND is cheaper than shift+AND. For stores the > difference is much bigger. Many CPUs don't have as much trouble shifting or extracting bitfields as x86 does. ARM for example has single-cycle bitfield insert and extract instructions. >> It's definitely true bitfields are grossly underspecified by the various C/C++ >> standards, but this is easily fixable. > > They specified just fine. IMHO. Maybe you never use zero-sized bitfields, enum bitfields, oversized bitfields... >>I designed a sane bitfield layout >> algorithm for the ARM ABI, which works for all types, sizes, alignments >> etc. Even details such as oversized and zero-sized bitfields are specified >> in a way that makes sense. It's being adopted by a growing number of >> compilers. >> > > Which is fine as long as the code is explicitly non-portable. Which, > BTW, too is fine most of the time (Nick is going to disagree). Actually it makes code explicitly binary compatible across multiple compilers. Wilco |