Found a very interesting interview of Pentax engineers about the K10D.
They are mainly talking about data acquisition/reading from the 10Mp sensor and mechanical consideration.

When switching from x86 to x64, it seems that Lame is getting about a 15% speed increase. Something to be considered is that in x86 mode we are using some hand-coded mmx and 3dnow functions, and some sse intrinsics functions (well, only 1 function right now), while in x64 we are only using the sse intrinsics functions. So the comparison is:

x86: mmx + 3dnow + sse
x64: sse only => +15% speed

In many benchmarks comparing x86 vs x64, when there is a speed increase, the speed up is more important on K8 based processors (Athlon64/Opteron) than on Core based processors (Core2). I've seen several articles implying, based on such tests, that there could be a non-optimal performance of Core processors in x64.

Let's try to find a possible explaination, based on Lame results.

*Lame is not using 64bits integer arithmetics, so speedup can not be caused by the ability to process this kind of computation in a reduced number of cycles.

*Lame is heavily floating-point based.

Speed increase could be because the compiler is vectorizing code to use sse/sse2 operations, which are always available in x64. However, experience demonstrated that current compilers are not good at fully automatic vectorisation, so it's unlikely to be the case.

As Lame is using single precision floating point arithmetic, we can also discard any (unlikely) potential speed increase of double precision arithmetic in x64.

The only remaining point that I can think of, is the fact that the sse ISA is register based while the x87 ISA is stack based, and x64 adds even more registers into the sse ISA.

Could it be because x64 is increasing the number of internal registers of the floating point units? Unlikely, as the K8 floating point core has 120 internal registers available, which is plenty.

The likely explaination is that sse code is more compact than x87 code. Sse is register-based, while x87 is stack based. In a stack based model, you have to first push your operands on the top of the stack, and only then you can do the calculation. In contrast, in a register based scheme you can keep data into other register while operating on new data, as you can do computation on data stored in any register, not just on top of the stack.

A point to consider is that the sse ISA is using 128bits registers, that K8 must process in 2 chunks of 64bits. It means that using unvectorized sse with only 32bits of data into registers needs to use floating point computation units twice (with 1 run totally wasted), compared to only once in x87, to just have the same computationnal result.
Despite of this, K8 provides a substancial speed up in floating point when comparing sse based x64 versus x87 based x86 mode. Obviously, it means that computation units are not fully loaded, otherwise the doubled computation would decrease speed.

It seems that K8 features good execution units, but that it's not optimally efficient into feeding them, and that sse based floating point in x64 helps it to feed its units.

This would mean that the speed increase witnessed in x64 is not because of the 64bits mode itself, but because it's helping an unoptimal decoding stage of K8. It would explain a few things:

*There is more speed increase when going from x86 to x64 on K8 than Core, as Core features a more efficient decoding stage (micro and macro-ops fusion).
*Speed increase when going from x86 to x64 is more important (on K8) in floating point based software than in integer based software.

This year, there is a trend toward increased sensor density in DSLR, mainly because of the new 10 megapixels cameras.
Many people (including me) are wondering about the noise level of those cameras compared to the lower density sensors. We have the following models that are in competition:

Canon 400D (10Mpix) vs Canon 350D (8Mpix)
Sony alpha-100 (10Mpix) vs KM 5D/7D (6Mpix)
Pentax K10 (10Mpix) vs Pentax K100 (6Mpix)
Olympus E400 (10Mpix) vs Olympus E500 (8Mpix)

The first constatation is usually that the 10Mpix cameras are producing more noise at higher ISO sensitivities. Comparing full scale crops side by side shows an increased noise level.

But there is something that should be considered: the increased resolution. Let's compare the noise of a 10Mpix to what a 6/8Mpix would gave you, but resized to 6/8Mpix. Once resized, it's not that obvious anymore that the noise level is increased.
So for 10Mpix DSLR we have:

*increased noise in full frame size
*similar noise when resized
*higher resolution
*similar noise level at low ISO
*lack of 3200 ISO setting (usually)

Seems that after all, the only real drawback might be the lack of 3200 ISO setting, but not really an increased noise level.

I am wondering about swiching my raw files to DNG, mainly because of space constraints.

Right now, my Minolta (5D) raw files are about 9 MB each one. Of course, it's quickly becoming (storage) space consuming, but I'm still reluctant to only keep jpeg versions. When you decide to edit a file, it seems to me that having the full 12 bits to start with is adding a lot more freedom, and seems to take care of the uniform areas that tend to appear if you use curves too much on jpeg files.

So I decided to have a serious look at DNG. I downloaded the Adobe DNG converter, and tryed it on a few files. The first feelings about the converter were positive:
*DNG converter is a single executable, no installation needed
*the converter is quite fast, and seems to be using all the available cpu cores
*it provided a great size reduction over the original raw files (about 30% smaller files)

Then I tryed to open the DNG files with Paint Shop Pro X, and things started to go wrong: even if PSPX is supposed to support DNG, it failed to open my newly created DNG files. I then tryed to browse the files using XnView, and it was displaying the files with some obviously broken parts. Quite disappointing. I think that it's likely that DNG support will improve in the future, a some camera manufacturers (especially Pentax) are starting to use it as a native file format in their DSLR, but it seems that right now there are still a few problems.

I still decided to have a look at the compressibility of my raw files:

original mrw file: 8.77MB
DNG converted: 5.13MB

A good size reduction, but:

zip: 5.79MB
bz2: 4.76MB
7zip: 5.13MB

So if I have some big storage space issues, I could still decide to use 7zip on my older raw files.

Conclusion: not yet switching to DNG