--- On Mon, 7/18/11, Kushal Kumaran <kushal.kumaran+pyt...@gmail.com> wrote:
From: Kushal Kumaran <kushal.kumaran+pyt...@gmail.com> Subject: Re: [Tutor] what is 'doubleword alignment'? To: "Walter Prins" <wpr...@gmail.com> Cc: tutor@python.org Date: Monday, July 18, 2011, 8:39 AM On Sun, Jul 17, 2011 at 9:15 PM, Walter Prins <wpr...@gmail.com> wrote: > > > On 17 July 2011 15:26, Lisi <lisi.re...@gmail.com> wrote: >> >> Sorry to be slow. Blame virtually no sleep last night ;-( But even were >> the >> power of two bit correct (and I see subsequently that it is not), how is >> 18 a >> power of two? >> > > The 18 bytes is a bit of an irrelevance. The point is that if the start of > the buffer falls on a dword (double word) alligned memory location then in > theory the access should be faster. The term is a little bit ambiguous > because strictly speaking different processors have different word sizes. > Even so, usually when people speak of double-word alignment, it's often the > case that the term word in such a context has its original meaning, e.g. 16 > bits. A dword is then 32bits or 4 bytes. A doubleword aligned memory > address is, using these assumptions, therefore an address that is divisible > by 4. Obviously if the word size is 32bits, then a double word would be > 64bits and a doubleword aligned address would need to be divisible by 8. As > an aside, this type of optimization is often taken care of by compilers > under the hood, and in any case it's generally not something that you'll > really be considering as a Python programmer. (If however you were working > on one of the Python runtimes or implementations, then you might well be > sometimes considering this type of thing, depending on exactly how > performance critical what you are working might be and what the runtime was > being implemented in.) > It's not just about performance. Some hardware simply cannot access data that is not correctly aligned. C programs that indiscriminately cast among pointers to types of different sizes are a pain to port off lenient architectures like x86. If you're writing C code that deals with pointers, you *always* need to keep alignment in mind. -- regards, kushal ===> Hello, Sorry for the late reply. Thank you all for your replies. I said '18' but I meant '16' (maybe my fingers are too big ;-). The text I put in my original post was from the documentation of a .dll/.so file (programmed in C). It was part of a procedure that reads out data. Each variable is 8 bytes or (for string variables) mutliples of 8 bytes (and each byte is 8 bits). I am using struct.unpack and ctypes to process the data in python. It works now, although I still want to read more about this. Where does the distinction little/big endian enter this story? Thanks again, I appreciate it! Albert-Jan _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
