RawShooter Essentials is commercially dead since Adobe bought Pixmantec. However, it's still a quite useful little application, that you can find using your favorite search engine.

RSE doesn't know about Samsung GX-1L. This camera is in fact identical to the Pentax *istDL2, with a different brand and a bit cheaper. The raw file format of both cameras is identical, except for the camera identification string.
If you edit the RawShooter Essential 2006 executable, and replace the "PENTAX *istDL" string with "GX-1L" (add some extra spaces at the end of the string to keep the same string length), then RSE is able to open raw files (.PEF) from the GX-1L.

This trick is also likely to work (but not tested) with Samsung GX-1S, which is identical to Pentax *istDS2.

If you want to run LightZone under an 64 bits version of Ubuntu (in my case Feisty/7.04), you will quickly discover that it does not work out of the box.

Here is how I solved it:

*download latest LightZone 2.4 from here

*download LightZone 2.1

*unpack both versions

*replace the java runtime of version 2.4 by the one provided with version 2.1

*in jre/lib/i386/jvm.cfg, add "-client KNOWN" at the first line

I recently bought a new laptop to replace my old one (an antique PIII-1100MHz).

I naturally bought one able to run in x64 mode. It was bundled with a professional version of Windows Vista. That's nice, as the home version would have annoyed me, due to the lack of many things that I consider to be mandatory for a sane operating system (real user rights management,...)

As we are in 2007, I naively thought that I should be able to use it in 64bits mode. After all, there was many reports during the Vista development stating that Vista would be bundled with both 32 and 64 bits versions.

The real situation is unfortunately different.
The OEM version pre-installed on my laptop is still a 32bits version, even though the computer is perfectly 64 bits-able. On the positive side, the Vista license agreement (professional version) clearly states that you can use one of those alternative versions of Windows if you want:

*Windows XP media center edition
*Windows XP tablet PC edition
*Windows XP professional
*Windows XP professional x64
*Windows 2000 professional/workstation

Those are the so-called "downgrade" rights granted by Microsoft.

This seems to be a positive thing to me, but I initially thought that I would have no use of it (after all, I already paid for a Vista pro version).

As this laptop only features a 32 bits version pre-installed version, I downloaded a 64 bits version of Vista professional.
Surprise, surprise...
The OEM key of my 32 bits version does not work with a 64 bits version!
I asked Microsoft (in my case Microsoft France) about it, and the reply was that if I was interested by a 64 bits version of Windows Vista, I should ask my usual software retailer about it in order to buy one. In other words, even if I already bought (bundled with the computer) a Vista professional version, I should buy once again a new one in order to have access to the 64 bits version.

A bit pissed (well, more than a bit) about it, I still decided to try installing an x64 version of Windows XP. First task: locate CD/installer. Microsoft silently ignored my question regarding how to obtain a genuine installation CD, so I had to download an ISO image from a peer to peer network.
After installation, I have unfortunately found a big stopper: as my laptop is relatively new, a few drivers were not available for XP x64, including the Nvidia graphic driver.

The unfortunate conclusion is that I had to revert to the 32 bits version of Vista that was bundled with my Laptop.

As I really want a 64 bits able operating system (in order to develop 64bits applications), I decided to download a 64 bits/AMD64 version of the Ubuntu Linux distribution.

It seems that in my case, Microsoft did a really smart marketing/commercial decision leading to:

* an annoyed customer
* a good way to slow down 64 bits adoption
* made me download and try a Linux distribution

Way to go!

Today, I played a bit with loops unrolling and AMD Code Analyst.
One of the ways to unroll loops in C is to use a Duff's device. While a bit strange at first, this is quit handy for quick loops unrolling.

While having a look at the generated assembly code with and without it (compiler is Visual Studio 2005/8), I noticed a few interesting things:

*VC8 is able to unroll loops, provided that the number of runs is known at compile time. My loop should run 16x, and VC8 unrolled it 4x. It might seem trivial for a compiler, but I don't remember previous versions having this ability.

*On a Core2, my "manual" 4x unrolling (using a Duff's device) is still faster than the 4x auto-unrolled produced by VC8, due to different instructions scheduling.

The generated code flow is a bit different in both cases:

*VC8 auto-4x-unroll features a "continue" jump at the end of the code block for looping, targeting the beginning of the code block. In my 16x loop, this jump is followed 3 times, and skipped the last time.

*My Duff's version features an "exit" jump after the first part of the unrolling (1*code - conditional jump - 3*code). This jump is skipped the first 3 times, and followed on the last pass.

The interesting point is provided by Code Analyst, and its pipeline simulator. I used it to simulated an Athlon64 pipeline, and looked at the result:
In the case of the Duff's device, the exit jump is mispredicted 3 times, leading to the Duff's version being slower than the automatic VC8 unrolling. This being mispredicted 3x, it means that an Athlon64 is unable to predict such a branch, always predicting it to be followed.

However, the code is faster using Duff's device when running over a Core2. That means that using a trick such as this will perhaps increase performance a bit on Core2, but will quite reduce speed on Athlon64, by conflicting with its branch predictors.
Considering that VC8 is able to unroll some loops by itself, we should better think twice before playing with tricks such as Duff's one.