Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Heard on .NET Rocks!: Pobar and Abrams on the CLR : Page 2

Carl Franklin interviews two distinguished members of the CLR team, Brad Abrams and Joel Pobar, resulting in a great discussion about memory management, the JIT compiler, NGEN, and more. They answer the question: "If you had it to do over again, what would you do differently?"


advertisement
.NET Rocks (continued) Brad Abrams: Yeah, I mean, it still does some set of the checks at NGEN time where you could actually verify at that time, and then there [are] some checks that can't happen at compile time.

Carl Franklin: And of course other code that depends on it that isn't JIT-ed still has to JIT. Brad Abrams: The other problem that we saw in 1.1 is that we had parts of the image still in IL and some in the NGEN image, so we still double load both images. So, in fact, if you look you see two copies of Mscorlib, for example, because it's NGEN-ed. And so one of the big things we did in Whidbey was make that the only one copy and that really helps you.

Carl Franklin: Okay. I think you just answered this, but are all the framework assemblies NGEN-ed or just some of them? Brad Abrams: Most of them are. So the rationale of when you shouldn't NGEN is actually pretty interesting to understand. If you are writing a high-throughput app like a server type app when what you need is raw throughput then you shouldn't NGEN it. And you actually probably don't care so much about working set and you don't care so much about start up time. What you care about is requests per second and it turns out that to get the magic of NGEN to work we need to put some indirections in. And with JIT we can just spit exactly the instructions we need with no fix-ups needed. So, for raw throughput, even in .NET Framework 2.0, you will be off not NGEN-ing.



Carl Franklin: It's really the load time that we are saving, right? Brad Abrams: Yeah its load time and working set, that's right.

Carl Franklin: Interesting. Richard Campbell: These are fun constraints to deal with in development. It depends on your project as to which things are going to be more important to you. Performance is not just [the] number of instructions executed in the given second. How much memory you ate, how much IO you executed around it, and so forth. Those things matter too.

Brad Abrams: [You're] absolutely right. One other thing on NGEN I just want to mention is-we don't quite have a ship plan yet but one thing we are really missing in the NGEN scenario is profile-based optimization so that we can actually reorder the basic blocks of the engine image based on actual usage scenarios. So the parts of your classes and methods that you use a lot will be early on in the image and together on pages and that reduces the number of page misses. Richard Campbell: We see technology like this from the Office team?

Brad Abrams: So Office uses this and in fact we use this internally and we are working on a plan to get that going. Richard Campbell: Out to us regular mortals.

Brad Abrams: Yeah exactly. Richard Campbell: That would be cool.

Carl Franklin: All right here is another question I've got to ask you guys: Code Access Security: is this like the great feature that nobody ever uses? Am I far off base here? Brad Abrams: No, it is a cool feature. I think its one of the cool benefits of the CLR that you can, if your scenario demands, run in a semi-trusted environment. And that's really important for some scenarios.

Carl Franklin: And by the way, just let me say [that] I agree with you. I think it's incredibly important. But let's get back to the issue of adoption. Joel Pobar: But also the most misunderstood. Right?

Brad Abrams: Okay, go ahead Joel. Joel Pobar: My personal world is very much kind of command-line compiler based and language design sort of stuff but from my experiences when I go visit customers, go to these code camps and things like that, code access security gets ragged on quite a lot. And I have not really heard any justification for it other than, "Hey it's pretty complicated," and, "There [are] way too many dials."

Carl Franklin: I have a sort of a pet theory about this and it's just [this:] the reason that you see that is because it's completely against the programmer's nature to put restrictions on himself. Why would any programmer in their right mind want to reduce what they can do with their toolset instead of add more functionality to their toolset. And that's essentially what you have to do. It's an anti-ego thing, right? Brad Abrams: "Well, I should be able to do this."

Carl Franklin: It's "Wear your seatbelt in the Ferrari." That's what it is. (laughs) Richard Campbell: But all developers want to operate under administrator accounts instinctually. They eventually learn that seatbelts in Ferraris [are] useful.

Carl Franklin: Exactly. (laughs) Brad Abrams: Exactly. You notice the guys that are professional race drivers that do it for a living. They wear these big five-point seatbelts, right? They are serious about it.

Richard Campbell: And the helmet and the gloves and the Nomex® suit, and it takes an army to get them out of the car… there is a reason for this. (laughs) Brad Abrams: Yeah exactly. The professionals are all for the safety gear.



Carl Franklin is a frequent contributor to CoDe Magazine.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date