Xman Drupal

The introduction of omp task in OpenMP 3.0 allows easy parallelization of the famous quick sort algorithm. As OpenMP 3.0 support in GCC is relatively new, I like to compare its performance particularly the omp task with a commercial compiler Cilk++ which is designed to efficiently support spawn/sync mechanism. Conceptually, the omp task and the Cilk++ spawn/sync are very similar.

Quick sort chooses a pivot, partitions elements into [< pivot] & [>= pivot], and sorts the two partitions recursively. The implementation in my experiment performs partitioning sequentially, and sorts the two resulting partitions in parallel.

Experiment setup:

• AMD64 Phenom X4 9950 (2.6GHz)
• Fedora 10 x86_64
• GCC 4.4 svn revision 144773
• Cilk++ 1.0.2

OpenMP 3.0 has added an interesting construct called omp task, while Cilk++ is a compiler developed by Cilk Arts to easily parallelize a C/C++ program. It is interesting to see how we can parallelize the following simple fibonacci program.

Serial:

long fib_serial(long n)
{
    if (n < 2) return n;
    return fib_serial(n-1) + fib_serial(n-2);
}

On Fedora 64bit, exrdisplay is not able to display an .exr image.

$ exrdisplay lighting.exr 
Warning: Environment variable CTL_DISPLAY_TRANSFORM is not set; using default value ("transform_display_video").
Warning: Environment variable CTL_DISPLAY_CHROMATICITIES is not set; using default value (chromaticities according to Rec. ITU-R BT.709).
Warning: Environment variable CTL_DISPLAY_WHITE_LUMINANCE  is is not set; using default value (120 candelas per square meter).
Warning: Environment variable CTL_DISPLAY_SURROUND_LUMINANCE  is is not set; using default value (12 candelas per square meter).
Cannot find CTL module "transform_RRT".

Solution I: Set the CTL module path manually.

user$ CTL_MODULE_PATH=/usr/lib64/CTL exrdisplay lighting.exr

or

Solution II: Install the 32bit CTL library (OpenEXR_CTL-libs.i386)

root% yum install OpenEXR_CTL-libs.i386
user$ exrdisplay lighting.exr

or

Solution III: Link the expected CTL module path.

# This assumes the 32bit CTL library (OpenEXR_CTL-libs.i386) is not installed.
root% cd /usr/lib
root% ln -s ../lib64/CTL
user$ exrdisplay lighting.exr

After installing Fedora 10 with XFCE, when you try to customize your windows interface, you'll get the following:

"These settings cannot work with your current window manager (imsetting-xim)"

According to Fedora Project website, a bug in GTK2 is to blame. But we can't just wait for the bug to be fixed.

I simply use KDE display manager by setting /etc/sysconfig/desktop.

% cat /etc/sysconfig/desktop
DISPLAYMANAGER="KDE"

and restart your X windows (ctrl-alt-backspace) or restart your system.

Whether it is Sun Java plugin, IceTea plugin, I simply cannot type in a textbox of a Java applet. After much hacking, I found that scim-bridge is the one causing the problem. Killing off all the im-*, gconf-im-*, imsettings-xim, and scim-* processes immediately solves the problem.

I use scim-bridge because it can work with GTK or QT windows. Now looked like I can just use scim with GTK only.

I installed Fedora 10 onto my system where the "nv" driver does not work with my display card GF 6600LM. The installation ends up being a text-based installation. Nvidia driver is later installed manually. Surprisingly, now the X windows take up the tty1 instead of usual tty7 (ctrl-alt F7).

The problem occurs when I start the system into runlevel 3 in console, then "init 5" to start X. The X process is then hogging the CPU.

The /var/log/message is showing something like below:

localhost /sbin/mingetty[2369]: tty1: invalid character 0x1f in login name

Now I find that mingetty keeps respawning tty1.

Solution:

Comment out everything in /etc/event.d/tty1 and forget about the existence of tty1.
Or find a way to get the X windows started back at tty7 (ctrl-alt F7).

Unable to compile VirtualBox with the source package? Get errors like the following?

$ ./configure --with-gcc=gcc422 --with-g++=g++422
Checking for environment: Determined build machine: linux.amd64, target machine: linux.amd64, OK.
Checking for kBuild: found, OK.
Checking for gcc: Checking for as86: 
  ** as86 (variable AS86) not found!

Check if the following work helps. ;)

# Install necessary packages, including the following but not exhausive list. This requires root.
% yum install dev86 iasl pulseaudio-devel pulseaudio-libs-devel glibc-devel.i386 libX11-devel.i386 libXt-devel.i386 libXext-devel.i386 libXmu-devel.i386 compat-gcc-34 compat-gcc-34-c++ kernel-devel kernel-headers libxml2-devel libxslt-devel SDL-devel python-devel

# Obtain the source from http://www.virtualbox.org/wiki/Downloads

# Prepare and compile the source.
$ tar jxvf VirtualBox-2.0.2-OSE.tar.bz2
$ cd VirtualBox-2.0.2
$ ./configure --with-gcc=gcc34 --with-g++=g++34    # I was able to build with gcc424 and g++424 too.
$ source env.sh
$ kmk    # This compiles the VirtualBox. You may do 'kmk -j 4' if you have a quad-core processor.
$ cd ./out/linux.ARCH/release/bin/src    # ARCH depends on the architecture of your system.
$ make    # This build the kernel module vboxdrv.
% make install    # Requires root, to copy vboxdrv.ko to /lib/modules/`uname -r`/misc/vboxdrv.ko

# Load the VirtualBox kernel module.
% modprobe vboxdrv    # Requires root.

# Create a group of users for accessing the VirtualBox.
% groupadd vboxusers    # Requires root.
% chown root.vboxusers /dev/vboxdrv
% usermod -a -G vboxusers USERNAME    # USERNAME is your account username who should have accesses to VirtualBox.

# Logout and login for the group information to get updated.
# Check if your user is in group vboxusers.
$ groups    # This should show at least vboxusers

# Try running your newly built VirtualBox.
$ cd VirtualBox-2.0.2/out/linux.ARCH/release/bin
$ LD_LIBRARY_PATH=. ./VirtualBox

If you get the following error (happens in version 2.0.2),

VirtualBox: SUPR3HardenedMain: effective uid is not root (euid=500 egid=501 uid=500 gid=501)

try

% cd VirtualBox-2.0.2/out/linux.ARCH/release/bin
% chmod +s VirtualBox VBoxSDL VBoxHeadless

Save the script below to /etc/init.d/vbox and make sure it's executable. The script helps to load and unload the kernel module during system boot up and shutdown.

#!/bin/bash
### BEGIN INIT INFO
# Provides: vbox
# Required-Start: $syslog $local_fs
# Required-Stop: $syslog $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: The Virtual Box kernel module
# Description: The Virtual Box kernel module
### END INIT INFO

start () {
        echo -n $"Starting Virtual Box: "
        modprobe vboxdrv
        sleep 1
        [ -c /dev/vboxdrv ] && chown root.vboxusers /dev/vboxdrv && echo " OK"
        [ ! -c /dev/vboxdrv ] && echo "Failed"
        return 0
}

stop () {
        echo -n $"Stopping Virtual Box: "
        [ -c /dev/vboxdrv ] && rmmod vboxdrv && echo " OK"
        [ ! -c /dev/vboxdrv ] && echo
        return 0
}

restart() {
        stop
        start
}

case $1 in
        start)
                start
        ;;
        stop)
                stop
        ;;
        restart)
                restart
        ;;
        status)
                [ -c /dev/vboxdrv ] && echo "Virtual Box is loaded"
                [ ! -c /dev/vboxdrv ] && echo "Virtual Box is not loaded"
        ;;
        *)

        echo $"Usage: vbox {start|stop|restart|status}"
        exit 3
esac

exit 0

Then,

% chkconfig --add vbox    # Add vbox as a service.
% service vbox status    # Check if the Virtual Box module is loaded.
% service vbox start    # Load the Virtual Box kernel module.
% service vbox stop    # Unload the Virtual Box kernel module.

Though the script is rather ugly, it should work ok for our purpose.

A system booted up with a wrong date & time is extremely annoying. It happens to me once I installed the Fedora 9.

What happens is that Fedora 9 seems to treat the initialize the system time from hardware clock as UTC time no matter you choose to store it as UTC time or LOCAL time. It works fine if I store the hardware clock as UTC time, but that unfortunately screw up other OS in the system such as Windows.

--- New Solution ---
I simply upgraded to kernel 2.6.26 with CONFIG_HPET_EMULATE_RTC enabled. That solved my time problem.

--- Obsolete ---
I did a little work around for this, setting the system time with hardware clock in LOCAL time in /etc/rc.d/rc.sysinit (about line 745).

# xman: The system seems to read hardware clock as UTC time no matter I set to store hardware clock as local or UTC.
# xman: This force the system time set to local timezone.
hwclock --localtime --hctosys
# xman: Try to correct the timestamp of /proc and /sys.
touch /proc
touch /sys

Given a number n, I want to generate n number of 1s on the less significant bits. For example, when n is 3, bit mask = 0000 0000 0000 0111__2__. Observe that the bit mask is equivalent to 2^^n^^-1. The following codes try to generate the bit mask.

// Note that *long* is 64bit in this case, running on a 64bit Linux OS.
int i;
for (i = 1; i <= 64; i++) {
        printf("method 1: mask %d: %lx\n", i, (1UL << i)-1); // 2^n-1
        printf("method 2: mask %d: %lx\n", i, ~(~0UL << i));
        printf("method 3: mask %d: %lx\n", i, ~0UL >> (-i)); // obscure.
        printf("method 4: mask %d: %lx\n", i, ~0UL >> (64-i));
        printf("method 5: mask %d: %lx\n", i, ~((~0UL-1UL) << (i-1)));
        printf("\n");
}

However, method 1 and method 2 do not work when n is 64. Both of these methods suffer from shift overflow. When it shifts to the left by 64, the shift operator simply refuse to work, and return the original value.

Method 3 is surprisingly working correctly in my environment. Further study indicates that -i is converted to unsigned (large number), and applied mod 64 before the shift. It becomes equivalent to method 4. However, method 3 is not guaranteed to work with all standard compilers. Note that you can't shift by a negative constant e.g. –2.

Method 5 is just a longer way, start with 1111…10 bit pattern and shift left by n-1, then complement.