EsoErik

My upgraded server has no room for a DVD drive, so in order to install Gentoo, it had to be booted over the network. To do this I made a Gentoo installation in VMware Fusion on my Mac Pro. I then created a second Gentoo installation to be booted over the network in the VM's /diskless directory, roughly following this tutorial. The DHCP server at my particular location runs Tomato, which uses dnsmasq, requiring the following special parameters:The contents of /etc/conf.d/:

INTFTPD_PATH="/diskless"
INTFTPD_USER="nobody"
INTFTPD_OPTS="-R 4096:32767 -s ${INTFTPD_PATH} -l -p -c -vvvvvv -u ${INTFTPD_USER}"

I diverged from the Gentoo instructions again by using an initrd. The contents of /diskless/boot/grub/grub.conf:

title Diskless Gentoo Linux 2.6.31-gentoo-r6
root (nd)
kernel /boot/kernel-genkernel-x86_64-2.6.31-gentoo-r6 doscsi root=/dev/nfs ip=dhcp nfsroot=192.168.1.126:/diskless
initrd /boot/initramfs-genkernel-x86_64-2.6.31-gentoo-r6

Labels: Gentoo Netboot

Using Visual Studio 2008 on Vista x64, I encountered this error: "The 32-bit version of Visual Studio cannot debug 64-bit processes or 64-bit dumps."This occurred when I attempted to debug a project that builds an x64 DLL. Specifically, the DLL is a .pyd for a custom build of Python for x64. This .pyd is a boost Python extension built with Visual Studio rather than bjam so as to reduce modify / rebuild / debug cycle time.

Yet, Visual Studio is capable of debugging x64 binaries; I do so often for projects that generate 64-bit executables. I scoured every human readable project and solution file expecting to find a field inaccessible from the GUI that specifies the debugger executable to use for a project and found none. Comparing .suo files in a hex editor revealed no significant differences for projects that work vs those that fail. Finally, I stared for a long time at the project properties debugger pane.Thus, I divined the cause of the problem and a workaround: when Visual Studio resorts to searching the directories in the PATH environment variable for the command to debug, an assumption is made. In this circumstance, Visual Studio assumes that the command will result in execution of a 32-bit binary. When the command is specified as a filename with path, Visual Studio checks the architecture of the specified executable and launches the appropriate debugger, avoiding the problem.

Labels: coding, Python, Visual Studio

Coding in Python is sufficiently faster than coding in C++ that I do so wherever possible. Graphical interfaces and most file IO performs acceptably when implemented in Python; I use C++ only to implement the portions of algorithms that would increase application run time by an order of magnitude were they implemented in Python. Any increase in Python interpreter speed reduces the amount of C++ required to achieve acceptable performance.

The Intel x86-64 C++ compiler version 11.1 is expensive, but I've been pleased with the optimizations it delivers and its robust C++ support (I have written valid templated code that it compiles and MSVC 9 does not). Suspecting that I could significantly improve the Python interpreter's run times for some of my applications, I grabbed the Python 2.6.4 source and associate dependency sources. All of these I rebuilt with ICC 11.1 x64 targeting Core2 with MMX, SSE, SSE2, SSE3, SSSE3, and SSE4.1 enabled with /03 and global optimizations.

This resulted in ~15% run time reduction for my pure Python test application. Hoping for more improvement, I again rebuilt Python and its dependencies, this time with profile guided optimization logging enabled. I then re-ran my test cases and rebuilt again using the resulting logs. The resulting interpreter binaries execute my pure Python test case 31% faster vs the official distribution!

Labels: Optimization, Python

Images of my spare smart APC 2200 RM UPS's main board for a friend. AC IN is silkscreened above the connector that does indeed link to mains power:

Labels: hardware