My blog is worth $2,258.16.
How much is your blog worth?
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.
- 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.
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.
Good work Elliot!
Kaja has set up a wiki for paradox to document his Compiler + JIT + Interpreter in the making.
I added quite some documentation about my Garbage Collector IMGC there too for it will be used by Paradox.
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!
Rome, here I come
I’ll be on a school excursion to Rome for 10 days, from tomorrow Thursday the 6th of October untill Saterday the 15th of October.
Contact my twin, Bram, if you would have contacted me.
My wordpress.com blog finally has got an usage
The free wordpress.com blog I got will be used to dump my stupidest, most impulsive and chaotic thoughts or things I want to say.
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.
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)