Reply to: Thought for the day

[AtW]

When I've done performance tuning

If this is as true as your performance cars then all I say say is -

[threaded]

Well, I am not planning to target anything apart from x86 in it - so code should run on all, but I am actually interested into SSE instructions (supported by pretty much all modern x86s now) - they might just be ideal to speed data processing nicely - next week is going to be interesting for SKA

When I've done performance tuning I always come across at least one of my juniors making the same assumption.

It is a bad assumption.

Even the size of the L2 cache can have significance.

threaded in "I've achieved superlinearity, more than once, so ner ner" mode

[Fungus]

That's just stupid. They're both template container classes to help you out, neither are meant to be the best possible solution. If you really wanted performance, you should have used your own classes and optimised it to do exactly what you needed. And we don't know that you're comparing like with like here.

Frankly I've always thought STL was needlessly over complicated, and that the MFC container classes are much easier to use.

Not really. If you want reasonable performance off the shelf, then the STL is okay. And it is powerful. But yeah, roll your own if you want the best performance. Though that can take longer to implement.

For my recent heap walk code I wrote my own simple list classes as a) they run much faster than STL and b) they were easy to write. And it allowed me to use a simple pooled allocation scheme to avoid mallocs.

IMO the STL is well worth learning and more powerful than MFC.

I tend to roll my own whenever possible, and then save copies of my libraries, and re-use them at the next client.

A lot of the people at my current client are ex-UNIX bods, and there's an awful lot of open source code from Apache and others. It is another world.

Fungus

[AtW]

great stuff as long as you know which cpu[s] you're targetting

Well, I am not planning to target anything apart from x86 in it - so code should run on all, but I am actually interested into SSE instructions (supported by pretty much all modern x86s now) - they might just be ideal to speed data processing nicely - next week is going to be interesting for SKA

[scotspine]

great stuff as long as you know which cpu[s] you're targetting

or specifically, instruction set

[AtW]

i'd have thought that was an ideal area for some nifty assemby.

Problem with assembly is that you can't do it directly in .NET - you have to link DLL and make a function call - the costs of a call will exceed benefits of assembly unless you use it in a "batch" mode so that it does lots of work - this is something I am going to do next week as I have a couple of sections doing some custom-decompression that can be sped-up big time if I have complete control over registers.

[scotspine]

i'd have thought that was an ideal area for some nifty assemby. or better still, [why spoil a friday night?], some good old binary...

[AtW]

I mean this:

public int iPos
{
get { return oBits[oPos]; }
set { oBits[oPos]=( value<POS_MAX ? value : POS_MAX); }
}

oBits is a BitVector32 and oPos is BitVector32.Section - this code works slowly not because its a function call but because of BitVector itself - I already changed a few places in the past to deal with hex bitmasks directly - this code is likely to be inlined since its small, and performance gains were in region of 1000%.

The alternative code that you have written MAY be faster than bogstandard indexing of BitVector32, but it pays to bother calculate masks manually and use them as constants - sure pain in arse to maintain, but performance improvements are way too high to ignore.

[VectraMan]

I once wrote two programs to manipulate maps and lists. The first used STL, the second MFC. Guess which was fastest? Yup. The STL program was twice as fast as the MS one.

That's just stupid. They're both template container classes to help you out, neither are meant to be the best possible solution. If you really wanted performance, you should have used your own classes and optimised it to do exactly what you needed. And we don't know that you're comparing like with like here.

Frankly I've always thought STL was needlessly over complicated, and that the MFC container classes are much easier to use.

It's as if MS are creating a demand for geeks with specialist MS knowledge.

Well errr yeah. What's .NET if not a way to generate work for the industry and further their hold on it?

[ratewhore]

shoot me

[DimPrawn]

You mean this?

public int this[BitVector32.Section section]
{
get
{
return (int) ((this.data & (section.Mask << (section.Offset & 0x1f))) >> (section.Offset & 0x1f));
}
set
{
value = value << (section.Offset & 0x1f);
int num1 = (0xffff & section.Mask) << (section.Offset & 0x1f);
this.data = (uint) ((this.data & ~num1) | (value & num1));
}
}

[AtW]

Nothing is wrong, its just not as fast as doing bitshifts yourself - it sure is annoying to create bitmasks manually but its a LOT faster - with luck compiler will also inline those shifts, something it definately won't do for normal BitVector32 operations that use indexer - function calls are not cheap on x86.

Now interface really annoyed me by requiring to use accessors for variables (that were declared in interface) - rather annoying since I can't see any good reason for that.

[DimPrawn]

Perhaps you can be more specific about what is wrong with the BitVector32 class and I'll see if we can fix it for you?

[Fungus]

Performance of .NET's BitVector32 is disappointing and having to declare access to (interfaced) variables in interface classes seems to hit performance too.

I once wrote two programs to manipulate maps and lists. The first used STL, the second MFC. Guess which was fastest? Yup. The STL program was twice as fast as the MS one.

MS are agressive and well marketed, but often not the best. As an example, COM is widely used, and has helped me earn a living. But IMO it can be fiendishly difficult to maintain, especially for those unskilled in the technology. And the debugging support is awful. It's as if MS are creating a demand for geeks with specialist MS knowledge.

[Fungus]

I shall carry them in my heart all day tomorrow.
Probably.

Me too. It's exciting moments like this that make one's life worth living.