C# interview question

[minestrone]

Having witnessed a police project where the number of characters you could type in a criminal record was 256, because that's the number of holes that were in the punched cards that were used by the ancient system that they were supposed to be updating used to allow, I'm more than happy for people to think outside outdated boxes, ta. Doing things a certain way just because that's the way you've always done them (and is the only way you know how to do them) can lead to some fairly counter-intuitive solutions and unreadable code. The Shift operator is at best a legacy feature in C#.

SCRO CHS?



Anyway not done the type of programming to use shifts for feckin years, I could still tell you what it is though,

[Gentile]

SCRO CHS?



Anyway not done the type of programming to use shifts for feckin years, I could still tell you what it is though,

Yup.

[Gentile]

Aye. Back when I was coding an oscilloscope display on the bottom 8 lines of a Hercules mono card in graphics mode on a 12MHz 286, all in that funny 8086 assembler stuff.

Made all the difference.

You don't know you're born; my old difference engine, now that was a challenge, etc.

[VectraMan]

Just about on-topic, in that it involves a bit shift, is this technique for optimising division - part 1 of 3, the other two getting even more beautifully weird and wonderful

I used that once. It was blitting an image with alpha channel on top of another image with alpha channel, which comes down to:

da = s1a * s2a
r = ( ( r1 * s1a ) + (r2 * s2a ) )/ da
(and the same for g + b)

That's with not using pre-multipled alphas, which would have made it easier (but introduces other problems). All the multiplies and adds are easy enough (especially with MMX doing 4 calculations with clipping (i.e. 1 and 1/3 pixels) simultaneously ), but the divide was really hurting the performance.

I realised I could have a table of 256 one over values and then multiple the result by that, and divide by 256 by shifting right (all 1/3 pixels simultaneously again).. Mucho perfomance boost. I felt quite pleased with myself for thinking of it.

Shame I don't get to do that sort of work these days.

[doodab]

The problem with those sorts of coders is that they will take a simple problem and make it more complex for their own enjoyment.

That's an utterly preposterous assertion. People who actually know what they are doing tend to take a complex problem and make it simple. The ones that go the other way tend to do so because to them the simple problem is anything but.

[VectraMan]

That's an utterly preposterous assertion. People who actually know what they are doing tend to take a complex problem and make it simple. The ones that go the other way tend to do so because to them the simple problem is anything but.

WHS. I seem to spend a lot of time simplifying other people's code. And especially when you're talking about performance, doing less is always better and that typically means making it simpler.

If you break it right down to processor level, a shift is far simpler and much less work than a multiply.

[Gentile]

WHS. I seem to spend a lot of time simplifying other people's code. And especially when you're talking about performance, doing less is always better and that typically means making it simpler.

If you break it right down to processor level, a shift is far simpler and much less work than a multiply.

I'd need to disagree with that, VM. Whilst I don't think that merely knowing Shift operators is any cause for concern (any more than it would be a cause of concern for me if developers weren't familiar with them), I do think that anyone that would actually use these operators in production code outside some highly-specialised environments (e.g., ones where there are memory issues because of the device the code must run upon) is a developer I'd have concerns about.

I was interested by your comment earlier in the thread that "<<4 is a faster way to calculate *16". I'm always trying to expand my knowledge, and I was interested enough in what you said that I built a quick test harness that could run both of those calculations X many times in different threads. I couldn't control which processor they ran on in a .net application, of course, but the runtime probably ensured that for most of the runs they ran on different processors on my multi-core machine whilst it wasn't running any other applications.

I found that there isn't actually a difference in speed between those calculations. Sometimes one is quicker, sometimes the other, but most of the time it was a dead heat. And where there was a small difference on a particular run we were only talking about a few nanoseconds across 1 million iterations. The reason is as Nick pointed out earlier: in a .net application, whichever high-level language you're using gets converted at build time, first into MSIL, then into specific machine code instructions relevant to the actual machine you're running it on. The two threads with "<<4" and "*16" in my test harness were running identical processor-level code.

My reason for having concerns about any dev that would use obscure code in a solution written in a high-level language is twofold. 1) they'd be writing code that would be hard to understand and maintain, and 2) they'd be demonstrating they weren't aware that any of that other optimisation was going on (and perhaps they'd be missing an even better optimisation that the framework could have identified had it been given the opportunity to do so, such as the "mult" instruction someone mentioned earlier).

[eek]

I'd need to disagree with that, VM. Whilst I don't think that merely knowing Shift operators is any cause for concern (any more than it would be a lack of concern for me if developers weren't familiar with them), I do think that anyone that would actually use these operators in production code outside some highly-specialised environments (e.g., ones where there are memory issues because of the device the code must run upon) is a developer I'd have concerns about.

+1 and I would have equal concerns about the company allowing such tricks to appear their systems. It goes back to an instruction I used to give Perl programmers 15 years ago Yes you can do that way but as most developers aren't as twisted as you could you separate out the logic line by line rather than embedding it all in an unreadable mess.

You did miss out one fringe benefit of the shift method. It may save a couple of ms in the initial compilation. I wouldn't want to bet on that tho.

[Willapp]

So to summarise this thread, we're agreed that:

1) A good developer really should know what the bit shift operator is and what it does, and even be able to demonstrate such knowledge under test conditions.

2) A good developer should never use said operators in production code unless it actually aids in understanding what the code is trying to achieve, such as with image manipulation etc. It should not be done to prove how cool and knowledgeable one is, or under some misguided notion of 'optimization' since modern compilers will tend to produce the same output anyway (or may even be able to optimize code better if the developer isn't trying to interfere).

[Gentile]

@Willapp: I'd still disagree with your conclusion 1), since I don't think a good C# developer needs to know in detail what the compiler will do with their code any more than a good driver needs to know what the carburettor in the engine of the car they happen to be driving will do to achieve the optimum mix of fuel and air when they press the accelerator. And I wouldn't ask a question like this in a test, except perhaps in an effort to identify candidates that would mistakenly think it was a good idea to use that operator in production code written in a high-level language.