The AMD64 optimization manual specifies that the latency of INVLPG instruction is 101 cycles in 32-bit and 80 cycles in 64-bit mode. Considering that the TLB is so closely tied to MMU, CPU, and that no accesses to RAM are needed, I'm wondering why is it so slow? Even more interesting is the large (20%) difference between 32- and 64-bit mode.
How fast/slow is it on Intel CPUs? No idea. Their optimization manual gives instruction latencies only for a relatively small subset of instructions. INVLPG is not among them.
2006-12-24
2006-12-23
Ashgabat
After hearing the news about the death of Turkmenistan's president, I searched the net to find some pictures of the capital, Ashgabat. I found this site and all I could think of after seeing the pictures was "Wow. I want to go there." (despite that summer temperatures can rise up to 45 degrees Celsius) Colourful and a bit surreal. Jewel found in an ex-Soviet republic. Who would have thought?
Peter Gutmann on Vista content protection
His article is a very interesting read. A quote: "The Vista Content Protection specification could very well constitute the longest suicide note in history." The scary part is about automatic picture degradation while listening to music and its potentially disastrous consequences in medical applications where crystal-clear picture is needed for correct diagnosis.
2006-12-13
How to not debug programs
I was drawn to this article, titled "Signals as a Linux debugging tool", by a recent link on the OSNews site. The subtitle writes "Intelligent signal handling finds bugs faster". Two things are wrong about this article.
The first thing is that the author's code examples have printf function in a signal handler to output register values when a fault happens. This is undefined behaviour, as the printf function is not listed as async-signal-safe in the POSIX standard. Ironically, an article titled "Use reentrant functions for safer signal handling" is listed among the references.
The second thing is that the author suggests an unbelievably complicated way of finding bugs. Once your signal handler with undefined behaviour has dumped the values of registers to your terminal, you are supposed to use objdump to disassemble your program executable, find the faulting location, and somehow map it to your program source.
I wonder whether the author actually knows how to make a program dump core when it faults, what to do with the core file, and how to use a debugger, such as gdb. (Hint: debuggers are much more powerful and convenient to use than what the author suggests in the article.) It's surprising that such a misleading, low-quality article can show up on an IBM's web site.
The first thing is that the author's code examples have printf function in a signal handler to output register values when a fault happens. This is undefined behaviour, as the printf function is not listed as async-signal-safe in the POSIX standard. Ironically, an article titled "Use reentrant functions for safer signal handling" is listed among the references.
The second thing is that the author suggests an unbelievably complicated way of finding bugs. Once your signal handler with undefined behaviour has dumped the values of registers to your terminal, you are supposed to use objdump to disassemble your program executable, find the faulting location, and somehow map it to your program source.
I wonder whether the author actually knows how to make a program dump core when it faults, what to do with the core file, and how to use a debugger, such as gdb. (Hint: debuggers are much more powerful and convenient to use than what the author suggests in the article.) It's surprising that such a misleading, low-quality article can show up on an IBM's web site.
2006-12-06
Nokia 770
Recently I had the opportunity to get Nokia 770 Internet Tablet (basically for free - a loan on indefinite time). I declined. Previously I have owned both a PalmOS device (Visor), and an iPaq onto which I installed Linux. In both cases I couldn't think of anything useful I could use the device for. Otherwise it was just a waste of time.
This time I did have an idea - as a dictionary where I can note down new words, and as note-taker to replace my paper notebook. So I tried to play with it and it has the same problem as other PDAs - text entry. The on-screen keyboard you tap on is next to useless for real-time text entry. The handwriting recognition isn't much better. If you want high accuracy, you need to carefully and slowly draw letter by letter. I wonder why Nokia didn't buy patent for the Palm's Graffiti entry system. (Yes, there is an option of external Bluetooth keyboard. But that is too cumbersome - suddenly you have to fumble around with two small pieces of fragile equipment that you don't want to drop.)
An ideal PDA should come with software capable of learning natural handwriting. Here's how I imagine it could work. First you type in (using a keyboard) a relatively large text. Then you write the text (using your natural handwriting) on the PDA and let it figure out for what groups of letters composite pen strokes stand for.
This learning process would initially take more time, but it would be worth it in the long run. I don't think that today you can find a PDA which can in real-time recognize natural handwriting. Until such time comes, I think I will stick with pen and paper for taking notes
in real-time.
This time I did have an idea - as a dictionary where I can note down new words, and as note-taker to replace my paper notebook. So I tried to play with it and it has the same problem as other PDAs - text entry. The on-screen keyboard you tap on is next to useless for real-time text entry. The handwriting recognition isn't much better. If you want high accuracy, you need to carefully and slowly draw letter by letter. I wonder why Nokia didn't buy patent for the Palm's Graffiti entry system. (Yes, there is an option of external Bluetooth keyboard. But that is too cumbersome - suddenly you have to fumble around with two small pieces of fragile equipment that you don't want to drop.)
An ideal PDA should come with software capable of learning natural handwriting. Here's how I imagine it could work. First you type in (using a keyboard) a relatively large text. Then you write the text (using your natural handwriting) on the PDA and let it figure out for what groups of letters composite pen strokes stand for.
This learning process would initially take more time, but it would be worth it in the long run. I don't think that today you can find a PDA which can in real-time recognize natural handwriting. Until such time comes, I think I will stick with pen and paper for taking notes
in real-time.
Subscribe to:
Posts (Atom)
