| |
 |
Friday, January 10, 2003 |
.NET and dynamically typed languages
I just discovered that Pinku Surana (a fellow DevelopMentor instructor and the author of the HotDog Scheme compiler) has a blog. Pinku is very smart with an original and has always been a very entertaining guy to hang out with. While perusing Pinku's blog tonight I found a somewhat scathing criticism of .NET in relation to weirdo[1] functional languages. Pinku writes:
Dynamically-typed languages like Smalltalk, Lisp and Scheme treat all types the same (imagine all datatypes using object in the signatures). The type is checked only when an operation is performed. So the runtime doesn't care what types are floating around in your program until you finally decide to add two objects. Then it must check that they are both ints (or floats, etc) and call the type-specific "add" routine. To implement such a language on .NET, every primitive type and structure must immediately be boxed. The performance overhead of boxing for my Scheme programs is nearly 10x greater than the same program compiled as unverifiable code (no boxing, no type checking). Therefore, the .NET runtime is not suitable for dynamically typed languages. [Green Hat Journal]
Pinku proposes a number of schemes (get it? Gawd I'm a dork) to make things better for functional languages, and I think his criticisms are good ones. Yes, OO is the most popular paradigm today but there seems to be increasing interest in other models. I think I know just the guy Pinku should talk to to start getting his ideas into the commercial CLR. I was hoping Pinku would implement one of his ideas on the Rotor codebase, but as he said in another entry:
don't expect me to write one. I'm just too damn lazy.
I have this same problem sometimes...
[1] I was thinking of Nickieben Bourbaki's quote from his "Worse is Better is Worse" paper:
"Syntax, folks, is religon, and Lisp is the wrong one. Lisp is used by weirdoes who do weirdo science"
10:00:34 PM 
|
|
Are Assembly Names Case Sensitive?
There's been some discussion on the Mono list about implementing assembly resolution. This is a somewhat interesting topic to me, because the ECMA specification leave most assembly resolution issues up to the platform implementer. Version policies? GAC? config files? all optional. Mono, for example, currently uses a traditional search path to locate assemblies. Some traffic over on the Mono list today got me interested in a particular point- are assembly names case sensitive? Does the ECMA/ISO spec say anything about it? It's perfectly legal to create assemblies called "a" and "A" for example (compiling a.cs and A.cs in C# results in assemblies "a" and "A" for example). a.dll and A.dll can't coexist in the same folder on Windows, but they can on a Unix filesystem. And what about the GAC? I found that on Windows a.dll and A.dll are not considered distinct - you can't add them both. I found the relevant bit of the specification in Partition III section 6.2. A note there says:
Note: Since some platforms treat names in a case insensitive manner, two assemblies that have names that differ only in case should not be declared.
In other words, the spec doesn't care how things are done. For the Microsoft Desktop CLR implementation a note on MSDN says this:
The runtime treats assembly names as case-insensitive when binding to an assembly, but preserves whatever case is used in an assembly name. Several tools in the .NET Framework SDK handle assembly names as case sensitive. For best results, manage assembly names as though they were case sensitive.
This can probably loosely be translated as "some of our developers used strcmp() in their code instead of strncmp() so don't do that". This probably isn't an issue that would ever mean much in real life - it's easy enough to avoid creating case-sensitive Assembly names in your own code, and presumably other people's code will differ in version number and public key token, even if they have the same Assembly Name. Still a nice illustration of a policy that is left up to the platform implementer.
4:10:18 PM
|
|
Dynamic method dispatch != fast
I recently found Carlos Perez's blog. I'm not impressed so far with his list of reasons Java is better than .NET (I particularly disagree with reason# 2 - native support for tailcalls is a huge boost to dynamic languages, but I digress...). I was intrigued by one entry where he mentions an interesting paper with some awesome discussion of dynamic invocation and its relative cost:
Compilers for static languages make use of the closed-world assumption, that reads: "all code the application may run is known at compilation time". ...If all classes are known by the compiler, it's easy to optimize many virtual calls: for example, if some base class declares a method as virtual but none of its subclasses overrides it, then the method may be handled as non-virtual. Even for overridden methods, the compiler can often apply dataflow analysis to discover the dynamic type of a variable. For example, in "Base x = new Derived(); x.f();",.the first statement tells the compiler that x's dynamic type is Derived, although its static type is Base; so in the second statement, the compiler may invoke Derived.f() directly instead of using a virtual call. This makes possible to inline f() if this method is a good candidate for inlining. Unfortunately, if x was (assigned from) a parameter, a non-local variable, or the return of a non-inlined method call, the compiler cannot know much better than the static declarations. Languages in this category usually support dynamic linking (DLLs, shared libs), but this is a limited featured – specifically, calls to "external" methods cannot be optimized. [Benchmarking Method Devirtualization and inlining]
It's interesting to see that in the tests the author performed the CLR was not the fastest (!). Its performance was a respectable middle of the pack but, isn't IL supposed to be easier to JIT-compile than Java bytecode? In any case, the author gives a bit of advice we could all use:
Optimizers with counter-intuitive behavior may cause manual tuning to have adverse effect. Insert your own favorite "leaky abstraction" quote here...
12:41:00 AM
|
|
© Copyright 2003 Jason Whittington.
|
|
