Prexonite May 2008 Update
Downloads
Update
There have not been any significant changes since the introduction of the CIL compiler into the Prexonite, yet the current version comes with a number of performance optimizations regarding the generated CIL byte code.The majority of the built-in commands and types now use the ICilCompilerAware interface, which is used by the CIL compiler to let commands and types emit highly customized code. Calling println with no arguments for instance, results in a static call to void System::Console.WriteLine() directly in the compiled method.Similarly, type expressions in CIL functions are no longer implemented via type expression parsing but by directly referencing the corresponding singleton PType objects.But the most important improvement is the possibility to statically link Prexonite function calls in CIL compiled methods, which makes yet another hashtable lookup redundant at the cost of additional memory: A dynamically generated class has static fields for each and every function used by the compiled application. This can be a problem if you plan to re-compile your CIL-implementations, as dynamic type, unlike dynamic functions, cannot be garbage collected by design. It is, however, possible to disable the generation of such a class by passing false to CompileToCil.And on a side node: The often used library function struct has been implemented as a compiler hook for improved performance. By resolving the members at compile time one does not only save run time, but also removes the need for dynamic lookups, which in turn enables the use of CIL compilation for struct-functions. This is especially helpful for immutable structs.
)
What you are seeing here are performance improvements of 950 to 3’400%, but keep in mind that those are very specialized micro benchmarks and that unless your program exclusively consists of mindless foreach loops, you will not likely experience such speed-ups.Nonetheless, iteration over lists is a very important aspect of many of the programs I have written in Prexonite Script.
I think the basic types Int32, Double, Boolean and String are more suited for a statically typed environment, so my type system must allow me to provide wrappers around third-party classes/structs.Wrapping and unwrapping objects must be as transparent as possible. Return values from base class library methods have to be wrapped in their Prexonite equivalent.At the same time, it is not practical to write a custom wrapper for every possible C# or VB.NET library, so there must be some sort of universal wrapper for CLR objects. With users of Prexonite being able to write their own wrappers, it must be possible to have multiple wrappers for the same CTS type. Also, some wrappers might handle more than one type.The solution for Prexonite is the abstract class PType and some concrete subclasses, including the universal ObjectPType, which does all the late binding. Since Prexonite Script performs type checks at runtime, type information has to be associated with every data object, which is just what the class PValue does.What might surprise you, is the fact that Null is considered a type. Every null reference automatically has type Null. Unlike the sturdy null references in C#, instances of Prexonite Null are completely functional objects. They react to operators, can be converted to basic values (Int, String,...) and even provide a ToString method. However, Null does have a special position in the Prexonite type system: it is not possible to write and use your own null reference wrapper.
