Suzanne Cook - Developing the CLR, Part II | WM_IN

dotnetjunkie

Does the tour continue in a Part III ? Smiley

Minh
WOOH! WOOH!

Do you forsee a day where JIT'ed code runs as fast as unmanaged C++ code? I mean, that's theoretically possible, right? Just a matter of how efficient the JIT compiler compares the the C++ compiler? And you guys are working on a MSIL CPU, right?

dotnetjunkie

I don't think that's an issue. 99% of managed code runs without any performance problems today. And for the remaining few applications, you can always switch to faster hardware Smiley

. Which doesn't mean that the .NET developers at Microsoft don't have to care about performance while coding of course!!! Wink

dotnetjunkie

LOL, is this an old homepage of Suzanne Cook?
http://www.cs.utah.edu/~scook/

Smiley

Must be with all the geek stuff on it! Smiley

It was funny to see that video clip on the front page! I've seen it on TV many times, it was made here in Belgium (where I live).

Minh
WOOH! WOOH!

dotnetjunkie wrote:
I don't think that's an issue. 99% of managed code runs without any performance problems today. And for the remaining few applications, you can always switch to faster hardware . Which doesn't mean that the .NET developers at Microsoft don't have to care about performance while coding of course!!!

I think there's a real noticeable difference in GUI apps.

rhm

dotnetjunkie wrote:
LOL, is this an old homepage of Suzanne Cook?
http://www.cs.utah.edu/~scook/

Web stalker alert!

Minh
WOOH! WOOH!

Beer28 wrote:

Have you tried the gnu jcg compiler?

http://gcc.gnu.org/java/

.NET has the equivalence in NGEN -- the Native Image Generator -- that compiles the entire .NET assembly right away to x86 code. If they can stick an optimized .NET compiler into NGEN, then it'd be darn close. Maybe that new Unified Compiler that Research is working on can be it.

Beer28 wrote:

If they made a CPU that took managed instructions, it wouldn't be managed or portable code anymore. That and the CLR inside the CPU that did the virtual stack for objects larger than 32/64 bit ect... and recognized object references would be horribly complex for hardware embedded software, could never be updated. You could possibly make it flashable, but can you imagine grandma flashing her CPU? **

OK, I'll let the Managed CPU idea go. How about a Managed Extension card. Maybe kind of like a Graphics Co-processor. Kinda like back in the days you'd buy Expanded Memory cards to run Lotus 1-2-3.

PDoug

dotnetjunkie wrote:
LOL, is this an old homepage of Suzanne Cook?
http://www.cs.utah.edu/~scook/

Must be with all the geek stuff on it!

It was funny to see that video clip on the front page! I've seen it on TV many times, it was made here in Belgium (where I live).

Hey! That kid is me! At least that is the way I was when I was small. (This what my mother alleges. Of course I have no recollection of it.) Smiley

Minh
WOOH! WOOH!

Beer28 wrote:

You don't understand, gcj actually compiles to a native binary you can zip/tar and give to a friend and he can run it on his or her machine with the runtime "dll" just like you could with a visual basic 5-6 app by including msvbvm5-6.dll

Hmm... it seems I've misunderstood the function of NGEN.

Beer28 wrote:

gcj actually makes something tangibly reusable that you can distribute as a standalone with the support "dll", which in unix speak is a shared object file, .so.

Unfortunately, I don't have the time to commit to an entire new platform. For now, .NET is my koolaid.