FFS Microsoft

[mcquiggd]

You should see some of the code for their Biztalk - By default, all orchestrations are routed via a small hut on the outskirts of Mumbai, where a few grandmothers triple-key the data from one xml message into another and post it back second class, once a day.

It's no wonder that hardly anyone uses Microsoft software.

[bogeyman]

You should see some of the code for their Biztalk - By default, all orchestrations are routed via a small hut on the outskirts of Mumbai, where a few grandmothers triple-key the data from one xml message into another and post it back second class, once a day.

It's no wonder that hardly anyone uses Microsoft software.

No! That was the previous version of BizTalk.

I's all done by Eskimos now!

[mcquiggd]

You mean they undercut the indian grandmothers?

No job is safe... it will be the children of Cooke Island next.. they'lll do anything for a bag of nuts (no rude comments please!)

[AtW]

Cut the crap - how did you do the swap then?

I left swap of vars as is because overall sorting now runs fast enough to be off my radar - now some of my code is on top in terms of low performance and I will first deal with it and then revisit the sorting one part of which will be getting rid of that variable they used to swap. What will I use? I will use registers because during sorting keys have to be loaded into registers in order to be compared, thus I will already have it in registers that I can just write to relevant memory locations.

The point here is simple - if I was working for Microsoft writing Sorting related code I'd make damn sure it has got top performance - the question of maintanance, easiness to read code, etc are totally irrelevant - in sorting its the performance it matters, otherwise everyone would just use easy to read bubble sort.

[bogeyman]

I left swap of vars as is because overall sorting now runs fast enough to be off my radar

I smell bulltulip

How are you going to do it using registers then?

[AtW]

__asm mov eax, first /* Move first into eax */
__asm mov ecx, second /* second -> ecx */
__asm mov first, ecx /* ecx -> first */
__asm mov second, eax /* eax -> second */

There is no x86 opcode for moving one memory value into another memory, it has to go through registers. In our case these variables will remain in registers before they need to be swapped (for keys), which means there will be no need to load them: this is the kind of hand optimised assembly that should have been written to make sure Array.Sort runs as fast as possible.

Anyway, in my case Array.Sort accounted for 75% of runtime, now it accounts for 10%, low enough to get off my radar for some time.

[bogeyman]

__asm mov eax, first /* Move first into eax */
__asm mov ecx, second /* second -> ecx */
__asm mov first, ecx /* ecx -> first */
__asm mov second, eax /* eax -> second */

There is no x86 opcode for moving one memory value into another memory, it has to go through registers. In our case these variables will remain in registers before they need to be swapped (for keys), which means there will be no need to load them: this is the kind of hand optimised assembly that should have been written to make sure Array.Sort runs as fast as possible.

Anyway, in my case Array.Sort accounted for 75% of runtime, now it accounts for 10%, low enough to get off my radar for some time.

Good move.

Still, it shows up the poor x86 design. Any decent processor would have 'swap' and 'compare and swap' register-to-register opcodes.

[AtW]

There is such opcode on x86, its called xchg - but the end result that you want is to update vars that are in memory, so no point to swap between registers. In our case here for keys that are being compared we will have them loaded into registers already in loop just before swap taking place, so they will already be in registers so this swap will be very efficient. I am sure Microsoft does that in their external routine TrySZSort which they call in some cases, its very fast but they fallback to less effective code - now appears incorrectly, so making mere explicit call to it with some changes to code to avoid boxing/unboxing in .net made is much faster - real shame Microsoft did not do it themselves, sorting is just such an area that should be optimised for performance as much as possible.

IMO Microsoft made big mistake by not allowing easy writing of ASM codes right in C# source - this would have made it more competitive with Java in terms of performance.

[Jabberwocky]

There is such opcode on x86, its called xchg - but the end result that you want is to update vars that are in memory, so no point to swap between registers. In our case here for keys that are being compared we will have them loaded into registers already in loop just before swap taking place, so they will already be in registers so this swap will be very efficient. I am sure Microsoft does that in their external routine TrySZSort which they call in some cases, its very fast but they fallback to less effective code - now appears incorrectly, so making mere explicit call to it with some changes to code to avoid boxing/unboxing in .net made is much faster - real shame Microsoft did not do it themselves, sorting is just such an area that should be optimised for performance as much as possible.

IMO Microsoft made big mistake by not allowing easy writing of ASM codes right in C# source - this would have made it more competitive with Java in terms of performance.

Nonsense - it is the job of compilers to do this sort of micro-optimisation.

[madhippy]

I left swap of vars as is because overall sorting now runs fast enough to be off my radar - now some of my code is on top in terms of low performance and I will first deal with it and then revisit the sorting one part of ..

can't say I've ever worked on anything that needed so much fine tuning ... what sort of stuff are you working on ?