A fast interpreted language

How can one claim that an interpreted language is fast?

Easily. If you implement the language using itself and the resulting interpreter is faster than the original then this means that the interpreted language manages to imprint the prorgammer's intentions to the C language (or assembly) better than the programmer herself.

For example, I may create an interpreted language named V using C and try to make the implementation as fast as I can. Of course this means that I have to implement a number of data structures and handle them. Also I have to optimize code path etc etc.

Then I re-implement the V language using the V language itself. If the re-implementation if faster than the original implementation then this means that the interpreter's logic produces faster code than me.

Well... here it is. The Python implementation in Python is faster than the Python implementation using C!

Read: It is very probable to end up with a faster program if you write it using python instead of C because the language will do better than you will in optimizing your data structures and your code. Just like it is better to write C than assembly and let your compiler to produce the optimized assembly code.

World's smallest IPv6 compatible web browser program

For a long time now I've become a fan of the python+Qt combination. It is great to have an easy to learn, easy to use language with great portability and minimalistic syntax.

The following program has become my favorite showcase for python. To my knowledge, it is the smallest, easier to understand, portable, IPv6 compatible web browser in the world.

If you have IPv6 connectivity just lunch python and copy-paste it save it to a file and run it (it may crash python otherwise):

[python]
from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4.QtWebKit import *

app=QApplication([])
win=QMainWindow()
w=QWebView(win)
win.setCentralWidget(w)
w.setUrl(QUrl("http://ipv6.google.com/"))
win.show()
app.exec_()
[/python]

If you don't then you can try the IPv4 version:

[python]
from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4.QtWebKit import *

app=QApplication([])
win=QMainWindow()
w=QWebView(win)
win.setCentralWidget(w)
w.setUrl(QUrl("http://www.google.com/"))
win.show()
app.exec_()
[/python]

In order to be able to run it you'll need the Qt4 library and the python Qt bindings. If you're under debian just run:

[bash light="true"]
# apt-get install python-qt4
[/bash]

This should work at least under Linux, Windows, Maemo and perhaps Symbian.

Double slit experiment

Some time ago I read this and show this (The whole list here, especially the double slit experiments series) and this and this. Then I read some more and more.

While this is really amazing I wanted to test it myself. The following is an easy setup that anyone with a somehow programmable camera (i.e. you can change shutter speed) and a common laser pointer can do.

Results

Here are the results of 3 different experiments (you may need to click on the photos for better resolution):

Experiment 1:

• One slit:


• Two slits:

Experiment 2:

• One slit:


• Two slits:

Experiment 3:

• One slit:


• Two slits:

Amazing eh? :-)

Do it yourself

You can test it yourself. For the experiment you'll need:

• Blu tak


• Pencil leads


• A laser pointer


• Some batteries for the laser pointer


• Black thick paper (e.g. black carton. I used a black folder)


• A camera where you can change the shutter speed and (optionally) with optical zoom.

The setup will look like this:


Here are the steps:

1. First make sure you have fresh batteries for the laser pointer. I used 3 AA batteries instead of 3 LR41. They should last much longer (just compare their size :-). Both of them (AA and LR41) are 1.5V.


2. I used a paper clip to keep the button of the laser pointer pressed at all time. You'll need to find a way to have the laser on without touching it.


3. Get a small piece of the black paper and open a very small slit. Then put this in front of the laser and stick it at the bottom with the blu tak. This part ensures that only a small part of the laser beam will pass and that it will be very focused.


4. Using blu-tak glue together 3 pencil leads as shown here:
   
   This will act as your double slit. The laser beam that passes through the one-slit paper should drop on those pencil leads and light two slits.


5. Since light is tricky, you should make sure that no light passes outside of the two slits, so you will have to use two pieces of black paper to block light. See the setup picture for the idea. If you do it right, you should see the laser beam cut at the outside pencil leads.


6. Put the camera directly in front of the laser beam. To do this you'll have to first remove the pencil leads and aim at the beam. At this point you'll have to make some adjustments to height of the camera and the laser. That's why I used a book and a ruler bellow the laser pointer (moving it left-to-right allowed for smooth up-down movements of the laser beam).


7. In order to adjust the camera you'll need to become familiar with what moves what. For example, the beam is centered on the display by tilting the camera, while it is focused by moving the camera. Just do it yourself.


8. Use as much zoom as possible and turn camera focus to infinity. Then adjust the shutter speed to appropriate values (I used values between 1/15 and 1/90 IIRC).


9. From the first picture you'll be able to see the distances that worked for me. That's why I added the second ruler at the bottom of the image.

Here are two additional photos of the left and right sides of the setup:



After setting up the experiment you'll have to start testing it. First make sure that laser light passes between both slits and only between them. If you take a picture you should see something like the two-slit results (you may need to zoom inside the pictures to actually see it). Then move the black papers a bit to prevent light passing from one of the two slits and take another picture.

TATA! Now that you performed the experiment you may want to try and figure out why this happens. If you eventually figure it out you'll have solved one great unsolved quantum mystery. So simple yet so tricky!

Explanation of the experiment results

The easiest result to explain is the result of experiment 2: The first photo shows what the camera captured when laser light was passing from one slit while the second show the result when light was passing from both slits. It is clear that there is some interference at the second case. In fact, allowing light to pass from both slits results in areas that are darker than when light was passing just from one slit (!). It is easy to see the two-slits because there are vertical lines. The height of each vertical line is no more than some millimeters.

Same thing for experiment 1 (click on the photos to actually see it): At first you may believe that this is a problem with focus, but the focus was fixed for both photos.

Experiment 3 is more eye-catching because it shows two different effects: The large light bands are the result of light diffraction while the smaller patterns are interference patterns. Diffraction is also visible with naked eye. Just put a piece of paper between the laser and the stencil leads and you will see the light bands. Unfortunately I could not get a photograph because they were not visible at the camera (i.e. the photos just showed a single spot and some artifacts. Test it yourself. It's very impressing!)). Interference on the other hand is not visible with naked eye.

Let me end this post with a phrase from matrix: "Welcome to the real world"

And this month's medal of stup^H^H^H^Hcleverness goes to...

Internet Explorer for this.

Really, if MS was not MS but a company that was payed to write applications, making this information public should be enough reason not to hire them.

Let me rephrase the explanation: "If you give me a letter and say that this letter is only handed once, I will drop it because... well... because... no reason..."

Following the KB's logic, if a document expires after 1 second and an application takes more than a second to launch then it should not be able to open the file...

... and it gets better: If the document expires after 10 seconds, you should have 10 seconds to read it. Else the document will be closed...

... and finally: if you save this document to a file, the file should be automatically deleted after it has expired.

Those are not true, but according to MS's logic, they could be. Perhaps in IE10 :-)

Windows 2003 are idio^H^H^H^Hfunny

Virtualization has a lot of benefits. Especially when you are messing with windows machines. It is far easier to have a template machine and clone it on-demand instead of setting up a new window installation every time or using disk-cloning software.

However, no matter how easy one attempts to make his life, windows will react on that. Here is what is an unintentional (I hope so) effect of windows protection and AI:

Assume that you have a virtual machine under XEN and you want to use it as template, so you create a nice image using dd for future use. Now, this machine is up and running for some months.

You then want to create a duplicate of this machine, so you create a new XEN config, a new logical volume and you restore the template image on the logical volume. You then create the domain.

You access the console using vnc and attempt to login. At this point windows ask for activation so you tell them "OK.. activate over the network". At this point windows detect an IP address conflict (the other machine is running). Network activation fails because windows have disabled the network card and you can't login to fix this because you need to activate them first... That's obstacle #1

In order to fix the problem you shutdown the original machine to avoid having a conflict. Then you switch to the clone and attempt to re-activate them... Since the network interface is disabled (or the address is not applied) activation fails again... That's obstacle #2

Then you say "OK... I'l perform a reboot", only to find out that "shutdown" is grayed by default for windows 2003 server... That's obstacle #3

Finally you shutdown the machine the "hard way" and restart it. Then you attempt to login again and windows ask you "why did the machine shutdown unexpectedly?"... That's the irony...

So yeah... managing windows is fun :-)

Linux ethernet driver ring buffer

While performing some tests with a congested 10Mbps link, a strange thing happened: The link was congested only on one direction and both endpoint queues were RED queues. Based on the parameters and the queue size, the delay between those two links should be something near 170ms. However, the delay was much larger: >300ms (!).

The "problem" was the ring-buffer of the underlying driver (e1000). This one used a buffer of 128 packets which when added to the average 150 packets in the queue, resulted in >300ms delay.

You can see this buffer by running:

#ethtool -g eth0

And you can modify this buffer by running:

#ethtool -G eth0 tx 80

This is the transmit buffer which (when filled) adds to the delay of the local queue.

Of course, in normal use, this buffer is a good thing as it will allow to get higher transfer rates easier (from the POV of the operating system). But when making experiments, this little thing gets in the way.

Another thing is that there seems to be a minimum value for this number. For example, on this card:

Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller

the minimum value is 80 (using e1000 driver from kernel 2.6.32)

So beware and don't loose a week looking for this thing like I did.

NOTE: This is not related to the transmit queue length that is used on the interface, as shown by:

# ifconfig eth0
# ip link show eth0


Problems that went away when I switched from fglrx to opensource driver (radeon+kms+2.6.33)

For a long time ago, a computer connected to the Internet had an RV770 ATI card and used to use the proprietary fglrx driver. Yes... That was my pc...

Then the latest fglrx (10.2) wasn't compatible with the latest kernel (2.6.33) and that kernel supported Kernel Mode Setting (KMS) using the radeon driver. Debian also started to have appropriate libdrm and Xorg (+ driver).

So I switched to radeon/KMS driver... At first everything was not working and I blamed the radeon driver. However, as it was proved, even after uninstalling the fglrx driver it kept causing me problems. A couple of files were left behind and there was at least one file left diverted to the fglrx's one. To fix this problem one needs to examine diversions (dpkg-divert --list), use debsusm (e.g. debsums -s libgl1-mesa-glx) and reinstall the packages with checksum problems.

Finally, after switching to radeon/KMS the following things changed:

• The used memory after startup reduced from about 2.5-3GB to less than 500MB (!!!!). I'm not talking about card's mapped memory. I'm talking about system's memory.


• Everything runs a lot faster. It looks like system latency is greatly reduced. There are two kind of improvements: (a) KDE's desktop effects are smoother and (b) it looks like the latency is reduced. Somehow the effects seem to run faster because there is less delay.


• I stopped getting crashes of plasma when logging-in.


• KDE's effects stopped being disabled every now and then.


• Tearing disappeared (!).


• Compositing effects seem to use less CPU.


• Some sound-card issues disappeared. Every now and then the sound was muted after system startup, but not any more.

So yeah... I really suggest that you switch to radeon/KMS if you're using the fglrx driver. It sucks.

BTW, I also tested that to a laptop with an older ATI card and it had most of the above improvements as well. A colleague of mine also switched to opensource driver and show the exact same, dramatic reduce of memory usage.