Saturday, May 26, 2007, 06:05 PM - Operating systemsI 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.
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!
Thursday, April 19, 2007, 05:31 PM - OptimizationToday, 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.
Sunday, March 11, 2007, 11:47 PM - PhotographySony shown two new DSLR from the alpha line at PMA 2007. One (let's call it a10) is supposed to be a Minolta 7D replacement, and the other one (let's call it a1) is an higher range model.
Those are just mock-ups, not yet real cameras. However, that is still a quite good thing, as it states where Sony wants to go regarding the alpha line. Many Minolta users (including me) were wondering about still using the alpha system, or switching to other brands (with many people looking at Pentax and the K10D). It does not mean that everyone wants to buy a new higher end camera now, but it's important to know that there are higher end models than the current one (a100) planned.
This means a possible migration path, but also accessories, lenses (including third party ones), support,...
A good move from Sony in order to bring peace of mind to all the current Minolta users.
Tuesday, February 20, 2007, 05:48 PM - PhotographyRaw converters was an area with an obvious lack of open source offer.
Of course, basic solutions like using the UFRaw plugin for the Gimp or even directly using DCRaw from the command line were possible. But it only provides a minimal solution (not even mentionning that the Gimp does not yet support 16 bits per channel), and not really what I have in mind for a usable raw converter.
To me, a raw converter should provide at least the following:
*handling of raw files (of course)
*luma/colors global manipulations
*ability to copy settings between files
And a really good one would also provide correction tools (lens correction).
Rawstudio seems to be the first piece of open source software going in this direction. With a few version iterations, it could become something really nice, filling a need.
Now, please explain me why is there no Windows version available?