Our great sponsors
-
Btw. I initially analyzed the code generated by https://sharplab.io/ when I implemented the code generator and e.g. noticed that the code generated for loops causes a runtime exception on Mono (see e.g. https://github.com/rochus-keller/Oberon/blob/8e5713fe6a12fa0cd3ec89609cd08222b363ec04/ObxCilGen.cpp#L3073); but this seems to be a Mono issue; I had no problems running the code patterns generated by Mono ond .NET or CoreCLR.
-
Oberon is quite similar to Pascal; the only thing someone could consider "esoterc" are the upper-case keywords in original Oberon and Oberon-2; but I'm more interested in my own Oberon+ language version which is described here: http://oberon-lang.ch. I consider it to be a modern, lean language. The performance comparison of Mono and CoreCLR is just a by-product of my work on Oberon+. I wrote a Are-we-fast-yet version in Oberon+ (see https://github.com/rochus-keller/Oberon/tree/master/testcases/Are-we-fast-yet) my different compiler backends. C# is a great language, but much more complex than Oberon+.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
And as I understand now achieving optimal performance with CoreCLR requires inside know-how of RyuJIT and Roslyn (which I don't have anyway), i.e. ECMA-335 alone is not sufficient; the actual compilation target to achieve optimal performance with CoreCLR is therefore Roslyn, not ECMA-335; of course I could generate C# instead of IL, but then I would depend on the framework and slow down the compiler. My current code generator based on https://github.com/rochus-keller/PeLib is about 30 times faster than ILASM.