January, 2004

Posts
  • Eric Gunnerson's Compendium

    More on inlining...

    • 16 Comments

    Just came across this:

     

    Method Inlining

    There is a cost associated with method calls; arguments need to be pushed on the stack or stored in registers, the method prolog and epilog need to be executed and so on. The cost of these calls can be avoided for certain methods by simply moving the method body of the method being called into the body of the caller. This is called Method In-lining. The JIT uses a number of heuristics to decide whether a method should be in-lined. The following is a list of the more significant of those (note that this is not exhaustive):

    • Methods that are greater than 32 bytes of IL will not be inlined.
    • Virtual functions are not inlined.
    • Methods that have complex flow control will not be in-lined. Complex flow control is any flow control other than if/then/else; in this case, switch or while.
    • Methods that contain exception-handling blocks are not inlined, though methods that throw exceptions are still candidates for inlining.
    • If any of the method's formal arguments are structs, the method will not be inlined.

    I would carefully consider explicitly coding for these heuristics because they might change in future versions of the JIT. Don't compromise the correctness of the method to attempt to guarantee that it will be inlined. It is interesting to note that the inline and __inline keywords in C++ do not guarantee that the compiler will inline a method (though __forceinline does).

    Property get and set methods are generally good candidates for inlining, since all they do is typically initialize private data members.

    HINT   Don't compromise the correctness of a method in an attempt to guarantee inlining.

    From Writing High Performance Managed Applications

  • Eric Gunnerson's Compendium

    Why doesn't C# have an 'inline' keyword?

    • 21 Comments

    I got this question in email today, and I thought I'd share my response.

    For those of you who don't know, the 'inline' keyword in the C language was designed to control whether the compiler inlined a function into the calling function. For example, if I had something like

    int square(int x)
    {
        return x * x;
    }

    and used it here:

    int y = square(x);

    I would be making a function call for a single expression, which would be pretty inefficient. Adding “inline' to the definition would tell the compiler to inline it, effectively changing my use to:

    int y = x * x;

    and giving me the abstract of a function call without the overhead.

    Inline had some good uses in early C compilers, but it was also prone to misuse - some programmers would decorate all their functions with 'inline', which would give them no function calls, very big code, and therefore slow execution.

    That led to the next phase, where programmers would only put 'inline' on functions where they needed the performance. That kept the code smaller, but missed cases like the one I have above where the inlined code is smaller than the function call code, where you want to inline every time. These cases only got caught if the programmer noticed them.

    Finally, as systems got better, compilers got into the act, and started doing enough analysis to make good decisions on their own without 'inline' keyword. In fact, the compiler writers discovered that the heuristics that they put in the compiler made better choices than programmers did, and some compilers started ignoring 'inline' and just doing what they thought best. This was legal because inline was always defined as a hint, not a requirement.

    This worked really well for most cases, but there were some cases where the programmer really wanted something to be inline (ie override the heuristics). This was sometimes around as a request for the “inlinedammit!“ keyword, which showed up in VC++ in V6.0 (IIRC) as the nicer named “__forceinline“.

    So how does that relate to C#? Well, it doesn't, but it's an interesting story so I wanted to share it with you.

    For C#, inlining happens at the JIT level, and the JIT generally makes a decent decision. Rather than provide the ability to override that, I think the real long-term solution is to use profile-guided feedback so that the JIT can be smarter about what it inlines and what it doesn't.

     

  • Eric Gunnerson's Compendium

    Two more bloggers

    • 1 Comments

    Two more people:

    Grant Richins

    Dan Fernandez

     

  • Eric Gunnerson's Compendium

    Sneak Preview of Visual C# Whidbey

    • 2 Comments

    A new post on the MSDN dev center gives a great overview of the new features coming up in Whidbey (though there are a few language surprises that aren't in that doc that I hope to cover soon).

     

  • Eric Gunnerson's Compendium

    C# Feature Request - index available within foreach

    • 11 Comments

    dom (at least I think it's 'dom' - he's made a fair effort not to have his name anywhere on his blog page) asks for a language feature, and I respond

     

  • Eric Gunnerson's Compendium

    Another C# blogger

    • 1 Comments
    Jim Griesmer
  • Eric Gunnerson's Compendium

    Win32 API to .NET mapping

    • 0 Comments

    Brad Abrams talks about this new page on MSDN.

  • Eric Gunnerson's Compendium

    I'm worried

    • 24 Comments
    I usually don't post on stories that are related to politics, but I'm going to make an exception for this.
  • Eric Gunnerson's Compendium

    We've got blogs...

    • 2 Comments

    A number of new C# bloggers have showed up this week, and I promised I'd give some “props” for all my “homies” before they entered the “blogsphere” and are“assimilated”.(”Word!”)

    (And yes, if you're wondering why they all showed up at once, we decided to incentivize them (a word especially for Joe) to give blogging a try). (What do you think of my new “happening“ style of writing? Is it “money“, or is it “whack“?)

    Please treat them kindly, and give them warm milk and cookies if they appear tired or cranky. Some of them haven't posted yet.

    The following list is in order of number of posts:

  • Eric Gunnerson's Compendium

    Misc Athletic stuff

    • 2 Comments

    Saturday morning, I did a 90 minute ride, and I am happy to say that I have finally gotten used to my new pedals (SPD-SLs), and new shoes (Nike <whatevers>). Very comfortable, and a lot easier to get into and out of than my old normal SPDs. You can even walk on them (a bit) without danger to your bones. The ride was 36 degreees and a bit windy, which takes a bit of planning, but is better than than 30 degrees I rode in over the new year. At the end of February, I'm planning on riding Chilly Hilly, a short but hilly tour of Bainbridge Island. Later this summer, I'm hoping to ride RSVP.

    Sunday I spent skiing with my family, where I had only one comical fall. I say “comical” because I fell at speeds exceeding 2 MPH while trying to skate over to my ski class. The big news of the day is that my 9-year-old daughter skied two *long* runs (1300 vertical each) of somewhat cut up blue, and then at the bottom of one skied a bumped-out black diamond, only falling once when she hit some ice. It's going to be only a couple of years before she can ski better than her parents (who, with all modesty, are starting to be able to ski a bunch of terrain they previously were insufficiently skillled).

  • Eric Gunnerson's Compendium

    Anders Inteview: Generics in C#, Java, and C++

    • 4 Comments
    Part VII of Anders' interview series on artima is up...
  • Eric Gunnerson's Compendium

    blogs.msdn.com

    • 3 Comments

    You can access the microsoft blogs that are currently on asp.net on http://blogs.msdn.com. Mine is at http://blogs.msdn.com/ericgu.

    The msdn address is probably more likely to persist in the long run, so it's a better choice than the ASP one.

  • Eric Gunnerson's Compendium

    Comparing CLR, Mono, SSCLI and JAVA Performance

    • 3 Comments
    Comparing CLR, Mono, SSCLI and JAVA Performance
  • Eric Gunnerson's Compendium

    Testing the C# Compiler

    • 0 Comments

    How many tests does the C# compiler team have? Take a guess, and then go read Gus' post “Testing the C# Compiler”.

    Gus used to work for me when I was the C# compiler test lead, and he became test lead when I went to the gray side to be a PM (in case you're wondering, marketing is “the dark side“). The quality of the C# compiler is a testament to his team (though I'll take a small amount of credit for setting some initial direction)...

     

     

  • Eric Gunnerson's Compendium

    Rocketry and Soccer...

    • 7 Comments

    Early in September, I got a injury on my big toe while playing soccer. Well, it wasn't while playing soccer, it was practicing soccer, but those are really the same thing. Actually, to be honest, it was while coaching soccer, which still requires a fair amount of soccer skills.

    Okay, so I got kicked by a 9 year old, but she was big for her age.

    The result was that I couldn't kick my with my right foot for about a month, which gave me a great chance to improve my off-foot play (which, to be frank, needs a lot of improvement).

    Fast forward to about a week ago, when I found that that toenail had fractured 3/4 of the way across. If I didn't do something, it would rip all the way through, fall off, and I would probably miss at least a day of skiing. What I needed was some way to keep it together until it grew out.

    That night I got thinking about rocket building, and tonight I spent about 10 minutes adding an epoxy reinforcement to the nail.

    I did consider reinforcing it with a bit of fiberglass, but that seemed a little over the top. Perhaps carbon fiber would be a better choice.

  • Eric Gunnerson's Compendium

    Destructors and Finalization revisited

    • 2 Comments

    Most of the commentors on my destructors and finalizers post figured out the reason why we went with the destructor syntax - so that we could ensure that the base class destructor gets called. A few comments on the comments:

    Jeroen Frijters has some comments on what's wrong with C# finalization. It is true that there isn't a guarantee across other languages that the right thing will happen here - this area and the whole Dispose() area are ones where it would have been nice to come up with a cleaner way to support these comments.

    Finally, a comment on choosing the destructor syntax. It is true that we're overloading the destructor syntax to mean something different (to some, subtly different) from what it means in C++. We did the same thing with the “new“ keyword - it means something different in C# than it does in C++.

    I think we made reasonable decisions there. One could choose to make the opposite choice, but that would require you to come up with new keywords, which is a surprisingly hard thing to do (feel free to engage in discussion on what those should be in the comments).

    Another question for the comments. Do you like the “why does C# do this?” format, or would you prefer me just to tell you why we do something?

  • Eric Gunnerson's Compendium

    C# Coding Guidelines

    • 37 Comments

    I've been in a discussion today with one of our customers on good C# coding guidelines/standards, and I confess to not having any good references to give him.

    He was nice enough to send me a link to one that he thought was good, which happens to be by Juval Lowy at iDesign.

    If you have other coding guidelines that you think are good, feel free to add the to the comments, and I'll try to get them up on our C# dev center.

  • Eric Gunnerson's Compendium

    Helmet == Good

    • 9 Comments

    I've put in a ton of miles on my motorcycle, and a fair number on my bicycle, and thankfully, never found myself in a situation where I needed the helmet that I was always wearing.

    Yesterday, however,while skiing quickly (and fairly well, I might add...) down a somewhat chunked up blue (a dark blue, if you care...), I caught an edge, popped off my right ski, pitched forward, and whacked down hard on the back of my head, into a rather hard slope. And then twisted around, and popped off my left ski. Certainly my worst fall of the year so far, but I ended up with a slightly sprained left thumb, and some overstressed neck muscles.

    Helmets are good.

  • Eric Gunnerson's Compendium

    Whither "Ask a Language Designer"?

    • 15 Comments

    Simon wrote:

    “Any chance of the "ask the designers" column starting up again on your MSN community site?”

    The answer to that question is “Yes”, I'm hoping to get something more regular than once a year up there in the near future, but I haven't said anything because we have a bit of a history of overpromising in that area.

    If you have a question that you want answered, please add it in a comment

  • Eric Gunnerson's Compendium

    A Glove Story

    • 2 Comments

    I've been working the past few nights wearing a pair of IronClad gloves. Nice, comfortable, and no problems tossing around 2x4s or sheets of plywood. I can even open a can of my favorite beverage without taking them off (okay, I'll confess, my favorite beverage is STP).

    Recommended

  • Eric Gunnerson's Compendium

    Why destructors and not just Finalize()?

    • 11 Comments

    In one of the comments, Niall said:

    “I am curious as to why the C# syntax for a finalizer is the destructor syntax. It doesn't bother me one way or another, but I am still curious.”

    So I thought I'd devote a bit of time to that question.

    Say I'm writing some code that wraps some sort of resource. Here's the code I might write if C# didn't support the destructor syntax (and the class already has implemented the Dispose design pattern:

    class MyClass: MyBaseClass
    {
        IntPtr myResource;
        ... lots of stuff here...

        protected override void Finalize()
        {
            Dispose(false);
        }

         protected override void Dispose(bool disposing)
        {
            // free myResource here...
        }
    }

    That seems pretty straightforward. What's wrong with the code?

    The answer is the reason that we have a separate syntax. Please post your answer in the comments.

  • Eric Gunnerson's Compendium

    ...unreceptive to change...

    • 11 Comments

    In my “Minus 100 points” article, Shawn took me to task for the reasons why we didn't put 'with' in the language.

    Unreceptive to change is, when I think about it a bit, probably a true statement. We are fairly unreceptive to change - it took a lot of customer feedback to get us to change our stance on accessibility for properties. I don't think that is necessarily a bad thing - I think the best languages were designed either by a single person or by small groups, and I'm not a big fan of languages designed by committee (Ada comes to mind...). The C# Language Design Team is a benevolent dictatorship - we all have our say, but Anders is the overall custodian of the language design. I think that's important if a language is going to stay true to its philosophy.

    On a specific issue, we might appear unreceptive for a number of reasons.

    The first reason is that your request is probably not the first time we have heard such a request. We do take note of them (see property example above), but in most cases we've already spent a considerable amount of design time on the issue (by that I mean hours). In the case of 'with', we looked at what other languages had done, how well the construct worked, and then made the call on whether we thought it would be good to add it. We have a considerable amount of language design experience and familiarity on the team, which means we generally know the prior art fairly well. I'm sorry if this comes of as arrogant at times - we're working at doing a better job of communicating in this area.

    'With' was a very conscious decision, especially because it's present in both Pascal and Delphi, Anders' previous babies (okay, Pascal was really Wirth's baby, but Anders was involved with one of the more popular variants).

    As I said, we might choose to add it in the future, but given the divided nature of the customer feedback that we get, it's likely that we'll stay where we are.

    Eric

  • Eric Gunnerson's Compendium

    Funny post about google searches

    • 4 Comments
    Rory Blyth posts these thoughts about google searches...
  • Eric Gunnerson's Compendium

    Minus 100 points

    • 26 Comments

    When I switched over the C# compiler team, I had hoped that I would be able to give some insight into how the design team works, what decisions we make, etc. Language design is a very esoteric field, and there's not a lot written about it (though “Design and evolution of C++“ is a pretty good read). I had hoped that I would be able to do this with concrete examples, as that makes it much easier.

    I've been watching for candidate topics to write about, but haven't yet come up with any good ones. One of the problems is that features have a tendency to morph in design (and in whether they'll make it into Whidbey) as time goes by, and it would be bad for me to say, “we're talking about doing<x>“ and then have us decide it wasn't a good idea. Or, for us to decide that <x> doesn't fit into our schedule, or it would break existing code, or any of the other reasons that might cause us to pull a feature. We're generally not comfortable really talking about those things until the feature is in somebody's hands.

    In lieu of such an example, I've decided to write something a bit more abstract about how we look at things.

    ******

    I've been spending a lot of time answering customer questions about why we do (or don't) have certain language features in C#. (as an aside, yes, we will be getting more of this online on the C# dev center).

    In some of those questions, the questions asks why we either “took out” or “left out” a specific feature. That wording implies that we started with an existing language (C++ and Java are the popular choices here), and then started removing features until we got to a point where we liked. And, though it may be hard for some to believe, that's not how the language got designed.

    One of the big reasons we didn't do this is that it's really hard to remove complexity when you take a subtractive approach, as removing a feature in one area may not allow you to revisit low-level design decisions, nor will it allow you to remove complexity elsewhere, in places where it support the now-removed feature.

    So, we decided on the additive approach instead, and worked hard to keep the complexity down. One way to do that is through the concept of “minus 100 points”. Every feature starts out in the hole by 100 points, which means that it has to have a significant net positive effect on the overall package for it to make it into the language. Some features are okay features for a language to have, they just aren't quite good enough to make it into the language.

    A feature like expression filters in VB is in this bucket. Yes, being able to put a condition on a catch is somewhat more convenient than having to write the test yourself, but it doesn't really enable you to do anything new.

    Being able to have property accessors with different accessibilities was another example of this. We had some experience with users being able to specify different levels of virtual-ness (virtuality?) on different accessors in an early version of the language, and it was a really confusing feature, so we elected to remove it. We felt similarly about differing accessibilities, and so we left it out of the 2002/2003 versions of the language, but we got *so much* feedback from customers that we re-evaluated the utility of the feature, and decided to add it to the language in the Whidbey version.

    One can argue that we should perhaps have come to that conclusion earlier, but I don't think that being cautious is a bad thing when doing language design. Once you add a feature, it's in the language forever.

    I should also probably note that this isn't the only reason features don't make it into the language. Some features provide enough utility in the abstract, but when we go to come up with a workable design for the feature, we find that we can't come up with a way to make it simple and understandable for the user. That means that in some cases we like a feature in the abstract, but it's not in the language.

    There is also another class - features that we don't want to get near the language. But that would be another post.

Page 1 of 1 (24 items)