Month: October 2005

Memory Alignment Havoc

Memory Alignment is one of the most important concepts when working low-level with memory. The bliss of the x86 processor, which is very kind about alignment, has left me unaware of it for years. That was until Kaja mentioned it, and therefore I decided to rebuild my Gc.

Like err.. what you talking ’bout?

Data should be aligned in the memory. Why? Because the processor doesn’t see the memory as most programmers do. For the processor the memory isn’t an array of bytes, but rather an array of blocks. In the case of the x86 processor this is usually 4 bytes.

When I got a simple piece of code like ‘(*i)++‘ the processor will find the 4 byte block in which this 4 byte integer i is located, increments it and stores it.

Well.. it does this when i fits exactly in one block. When i is partially in one block, and the rest is in a second block (it is unaligned) the processor will have to fetch both blocks, reconstruct the integer, increment it, split it, and store it back.

This is a lot of extra work. The processor will spend a few times more work on a simple increment. Although the actual difference is only about 5% because requesting 2 blocks or 1 block doesn’t differ that much.

Because this means a lot of extra work for the processor, and even more transistors, some processor manufacturers decided to barely or not support unaligned data.

Summarized:

  • Some processors will just cope with unalligned data, although it takes a bit more time. (x68)
  • Other’s will throw an hardware exception and let the OS fix it up, which takes a hell of a lot more time.
  • A bunch will get unstable and the process crashes, or the whole processor will.
  • Ans some will silently ignore the unaligned data using the first aligned data that comes close instead which leads to silent corruptions and hard to trace bugs.

Bliss of C

Maybe this will shock you, at least it shocked me. Luckily you don’t need to worry a lot when you aren’t writing specific low-level applications like memory managers or compilers. Your C compiler will take care of alignment for you.

Gimmi more

Kaja wrote an article about memory alignment.
IBM has got an excelent article on it too.

Enter HashCash 3.0

A new anti-wordpress-spam release of Elliott Back: HashCash 3.0.

Basicly it uses md5, javascript and a bit of AJAX, which is very hard to force except when a spam bot executes the actual javascript.Basicaly it just keeps an “undecipherable” secret which in theory you’d need javascript to decode. The problem with that is that it takes some time to execute the javascript and hopefully will scare the spambot away.

The method isn’t intrusive (although it does require javascript to be turned on), and pretty effective.

Good work Elliot!

Back from Rome

I`m back indeed.

Rome is a great city.

Giolitti‘s ice-cream tastes great as does tazza d’oro‘s espresso.

Best building I visited was the pantheon. I like it more than the sixtian chapel, which is overrated in my humble opinion.

(Go Bernini! Boo Michelangolo)

Anyway, I could fill a few pages with my experiences, but I`m to lazy and too excited with my new toy: google reader!

Binary Multiples

Data size prefixes always have caused confusion.

How much is one MB?

Originally it’s 1024 kB, each kB is 1024B. This makes a total of 10243 bytes (1073741824).

Using 1024 instead of 1000 has its roots in the fact that computers usually work with blocks of 1024 bytes (210).

Other people stick to the SI and deem one MB 10003 bytes (1000000000).

To get rid of confusion binary multiples were introduced. One MiB = 10243, where one MB would be 10003.

Factor Name Symbol Factor Name Symbol
10001 Kilo k 10241 Kibi Ki
10002 Mega M 10242 Mebi Mi
10003 Giga G 10243 Gibi Gi
10004 Tera T 10244 Tebi Ti
10005 Peta P 10245 Pebi Pi
10006 Exa E 10246 Exbi Ei
10007 Zetta Z 10247 Zebi Zi
10008 Yotta Y 10248 Yobi Yi

When buying something one should take notice of this, because the difference between one GB and one GiB is 74MB (or 70 MiB).

With ever increasing storage capability there would be a time where one VendekaByte would be half of one VendebiByte. (Vendika = 1030)