Qualitative Code Differences in Managed Code

re: Qualitative Code Differences in Managed Code

Adam — Wed, 23 Feb 2005 01:01:00 GMT

Exception Handling: They're doing this because you (microsoft as a whole) told them initially this was the new way and that it was practically free.

In reality, its expensive and this advice was poor.

re: Qualitative Code Differences in Managed Code

Rico Mariani — Wed, 23 Feb 2005 01:07:00 GMT

See http://weblogs.asp.net/ricom/archive/2003/12/19/44697.aspx for more details on exception handling guidelines.

re: Qualitative Code Differences in Managed Code

Matthew W. Jackson — Wed, 23 Feb 2005 01:34:00 GMT

I personally believe that the lack of inlining for Value Types is the biggest issue in current JIT performance. I think that Value Types in general need much more aggressive inlining than reference types. If performance were not an issue, nobody would be using Value Types in the first place.

Special-casing of generics for Value Types is great (at the cost of a bigger working set), but the lack of inling makes it difficult/unworthwhile to create efficient lightweight wrappers for other primitive types that add additional features (like say a wrapper for Int32 that restricted its values, or implemented a generic interface such as IArithmetic<T> for doing math in generics). It also adds penalties when creating new primitive-like types (such as a Complex number).

Personally, I think that there should be really aggressive inlining on overloaded operators, property accessors, and constructors defined for Value Types, even if it increases the initial cost of JITing a Value Type a bit.

Most programmers do not "see" the added cost of calling an overloaded operator, and the runtime (or maybe even the C# compiler) should work as hard as possible to inline them.

Even System.Decimal would benefit from such changes to the JIT, and it is very frequently used in business applications.

re: Qualitative Code Differences in Managed Code

Stu Smith — Wed, 23 Feb 2005 11:08:00 GMT

With regards interop with unmanaged code, I wonder if you'd consider writing a post on suggestions for performance regarding crossing the managed/unmanaged boundary? We have a slight performance issue with the following, and I'm sure it must be a common scenario (even if not exactly the same).

We started our application (in C#) pretty much as soon as .NET 1.0 appeared. Front-end and business objects are written entirely in C#. We reused an in-house object/relational system that sits on top of the database, which we upgraded from straight C++. In the middle is an auto-generated data-access layer, with a pair of object/collection classes per table, and a pair of get/set methods per column. Business objects are stateless and only contain a reference to the data-acess object. These d/a methods have the form:

// MC++
Type Table::GetField()
{
// Type is 'simple': one of int, bool, System::String *, DateTime, etc.

Type value = m_pRow->GetValue( <fieldindex> ); // m_pRow is unmanaged.

GC::KeepAlive( this );

return value;
}

So obviously the interface is too 'chatty' but that's hindsight and can't be easily changed. How can we know if we're making the cheapest possible call here (you mentioned argument conversion and security)?

re: Qualitative Code Differences in Managed Code

Hallvard Vassbotn — Wed, 23 Feb 2005 12:39:00 GMT

> The current just in time (JIT) compiler is more limited than a typical commercial quality unmanaged compiler, partly because it needs to be smaller and faster and partly because it just isn’t as mature. Some of the larger issues include.

I recently read about the improved NGEN in 2.0:
http://msdn.microsoft.com/msdnmag/issues/05/04/NGen/default.aspx

The article indicates that NGEN works by invoking the same underlying JIT compiler. But at install time, there isn't the time constraint. Why can't NGEN use a more agressive optimizer than the JIT'er?

re: Qualitative Code Differences in Managed Code

Goran Pušić — Wed, 23 Feb 2005 13:20:00 GMT

On exceptions (first comment):

"In reality, its expensive and this advice was poor"

Not true. Exceptions have a cost, granted. But, the thing is, if they are used to actually handle errors (1/1000 rule from Rico's other post), the cost is not important. Why? Well, because if you have an error, the amount of processing to do is normally MUCH less than what's needed for normal operation (we write code to do stuff and not to handle errors, don't we? BTW, that's also why exceptions are good: they help us to have to write less code for error handling; that leaves us more time to write code that does stuff)

The important overhead, then, is the "static" one for exception handling init/cleanup. But, there, do not forget that you compare the compiler-generated code that you don't see, with code for error handling that you write. So, it's not that you have hidden overhead in case of exception-enabled environment as opposed to NOTHING in exception-free (C code, anyone?) environments.

re: Qualitative Code Differences in Managed Code

Jeff Atwood — Wed, 23 Feb 2005 15:37:00 GMT

> You (microsoft as a whole) told them initially this was the new way and that it was practically free.

Where have you seen this? Everything I've read, and I do mean everything, told me that exceptions are expensive and should be avoided-- eg, used for only "Exceptional" cases.

In practice, exceptions are brutally slow-- literally slower than a database query! But I'm fine with that, because I only use them in exceptional conditions as designed.

If you have read this somewhere (microsoft docs saying exceptions are free), can you provide a link to it?

re: Qualitative Code Differences in Managed Code

Dmitriy Zaslavskiy — Wed, 23 Feb 2005 20:06:00 GMT

Why can't CLR use thing like GetWriteWatch instead of memorybarrier?

re: Qualitative Code Differences in Managed Code

Jeffrey Sax — Thu, 24 Feb 2005 04:05:00 GMT

My vote for most pressing performance issue also goes to inlining value types. This should have been a priority from the outset, not an afterthought.

By their nature, value types tend to be used for small, fundamental types like complex numbers, intervals, quantities (size + unit), etc. Method bodies are usually very small. These value types are used in calculations, very often inside loops.

A second issue concerns mutable reference types with value semantics. These are sometimes necessary, but seem to run against the NET philosophy and their use is discouraged at every opportunity. One example: C# doesn't allow overloading of compound assignment operators. It just assumes your objects are immutable and therefore "operator synthesis" (x@=y -> x=x@y) is all you need.

The String/Builder pattern can't be used for objects like vectors and matrices. Like value types, these objects are used in calculations, implying that their component values change often. Recycling is a must. Bounds checking can often be eliminated if certain class-level invariants can be verified.

re: Qualitative Code Differences in Managed Code

Rico Mariani — Thu, 24 Feb 2005 05:00:00 GMT

Jeffery Sax's thoughts are closely aligned with mine. Of the JIT issues, the inliner is the thing I would most like to see improved and handling of value types in the inliner is doubly important. I think value types are largely under-used and perhaps they might be used more often if you could cash in, in practice, on the gains that they offer in theory.

But of course all the areas identified as weaknesses in the Jit above are obviously on our minds.

re: Qualitative Code Differences in Managed Code

Goran Pušić — Thu, 24 Feb 2005 09:37:00 GMT

Jeff:

"In practice, exceptions are brutally slow-- literally slower than a database query!"

I call bullshit! Care to show a sample program that times an exception and a DB query that proves this? I'll show you one where DB query is slower!

re: Qualitative Code Differences in Managed Code

Frank Hileman — Thu, 24 Feb 2005 14:23:00 GMT

Vote for inlining on value types:
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=fb7b3c93-a9e9-418b-85b3-b67a195c7e1a

This will make VG.net even faster.

re: Qualitative Code Differences in Managed Code

Ryan Lamansky (Kardax) — Thu, 24 Feb 2005 14:24:00 GMT

It's good to know that value-type inlining is on your (Microsoft's) minds. Not having it is driving me insane!

If I had the choice, I would give up every single one of .NET 2.0's new features in exchange for value-type inlining. Seriously.

re: Qualitative Code Differences in Managed Code

Rico Mariani — Thu, 24 Feb 2005 16:55:00 GMT

There was a question about GetWriteWatch() up there. It's an interesting strategy to use OS based information instead of write barriers but I don't think you'd net any performance doing it.

I see these problems:

-using GetWriteWatch will manipulate the page tables, that causes more TLB misses and loading CR0 ain't cheap anyway, we'd have to do this on every garbage collection
-once armed, you'll pretty much have to take the equivalent of soft page faults to clear the bit (the OS does this for you), those aren't cheap neither
-the granularity would be at the page level, so we'd have to assume a lot more pointers are dirty
-if we use that feature then others (like debuggers) can't, and it seems more useful to them than to us

At the end of the day Write Barriers aren't killing us.

re: Qualitative Code Differences in Managed Code

Rico Mariani — Thu, 24 Feb 2005 17:00:00 GMT

In order to get an exception to compete in slowness with a database query, you first need a pretty simple query. e.g. "select 1"

Obviously a highly complex query could take arbitrarily long.

Secondly, perhaps the biggest cost of the exception is gathering the callstack information. So you'd want to do the throw from a very deeply nested function.

So I could imagine a case where all that gathering is actually slower than a network round trip to a database but I don't think it would be the norm.

I guess the other factor is there could be an arbitrary number of finally clauses that did an arbitrary amount of work. So if you timed from the throw to the catch you might be waiting a while.

That's the thing about throwing -- you just don't know what is going to happen exactly -- it's both the strength and the weakness of the mechanisms generality.

re: Qualitative Code Differences in Managed Code

Dmitriy Zaslavskiy — Thu, 24 Feb 2005 20:01:00 GMT

Back to using OS info.
Like you said measure first. Do you guys have a prototype?
I can argue that in app that takes does little GC compare to updating it's structures this will be a significant win.
Extra code/data for wb will cause more data to be touched trashing TLB etc.
On large memory systems you would probably wont to have granularity bigger than even a page (sans large pages)
I am sure you would agree that this is nowhere near a clear cut desision.

And I didn't understand your last point about debuggers

re: Qualitative Code Differences in Managed Code

murphee — Thu, 24 Feb 2005 23:27:00 GMT

On Write Barriers:
If you're curious about the impact of
Write Barriers refer to this paper:
http://cs.anu.edu.au/~Steve.Blackburn/pubs/papers/wb-ismm-2004.pdf
(The Title "Write Barriers - Friend or Foe?" should tell you what it's about).

re: Qualitative Code Differences in Managed Code

Jeffrey Sax — Fri, 25 Feb 2005 17:07:00 GMT

Not all exceptions are thrown by code deep down in the call stack. Exceptions are often raised by the CLR because of an issue with code inside a method. For example: OverflowException on a checked block.

A form of 'light-weight exception handling' for these situations, where the JIT bypasses the full exception handling mechanism, would be very welcome. I.e. if a CLR exception is thrown by code inside a try block, and the exception is caught in a corresponding catch block, the overhead of building a full-featured exception object could be eliminated.

This is especially important since the CLI spec states that certain tests throw an exception if the test fails rather than branch if it succeeds. Example: the ckfinite instruction. In other words, without this type of optimization, the CLI *imposes* severe performance degradation.

I'm aware that exception handling code can be extremely complicated, but that does not mean that the simple cases cannot be optimized.

Blog link of the week 08

Daniel Moth — Mon, 28 Feb 2005 02:36:00 GMT

Blog link of the week 08

My Life as a Managed Code Junkie - Part 4

James Kovacs' Weblog — Thu, 09 Mar 2006 08:45:15 GMT

Gamefest 2007: The Costs of Managed Code: The Avoidable and the Unavoidable

Rico Mariani's Performance Tidbits — Sat, 08 Sep 2007 10:04:34 GMT

A few weeks ago I spoke at Gamefest 2007 where I delivered this talk: The Costs of Managed Code: The

MSDN Blog Postings » Gamefest 2007: The Costs of Managed Code: The Avoidable and the Unavoidable

Sat, 08 Sep 2007 12:36:36 GMT

PingBack from http://msdnrss.thecoderblogs.com/2007/09/08/gamefest-2007-the-costs-of-managed-code-the-avoidable-and-the-unavoidable/

Some notes on .NET performance « Handwaving

Some notes on .NET performance « Handwaving — Mon, 31 Dec 2007 21:35:43 GMT

PingBack from http://surana.wordpress.com/2007/12/31/some-notes-on-net-performance/