I’ve just discovered RemObjects and I’m liking what I’m seeing. I’m potentially moving from another language (Xojo) because I’m hitting the limitations of that tool with regards to performance.
I’m writing my own bytecode interpreter for a Python-like scripting language and I’m looking to rewrite the VM in a higher performance language. However, my only experience is with garbage collected languages (I don’t like C, etc).
I’m planning on rewriting my VM in Swift as I think that should be better performing than Xojo and I’d like to use Silver as the thought of writing Swift for both macOS and Windows is appealing.
My question is on the performance of code created by the Elements compiler. Does it compile Swift to native machine code? Would the performance of the emitted executable be comparable to the “official” Apple Swift compiler?
My experience as a VB programmer with Oxygene code is that it performs very well, much better than VB did - I don’t use swift, so I can not compare it with that.
But I see you come from Xojo, so you might also be interested in Mercury, the VB implementation of RemObjects (at this moment in Alpha).
I don’t mind curly brace languages like Swift, I just loathe manual memory management. Also I’m trying to learn Swift as I think it will be an important language going forwards over the next 5 years.
Our compiler can compile for man hy different platforms, including native code for Windows, Linux, all the Apple OSs and Android NDK, in addition to WebAssembly, .NET and Java/JVM/Android SDK (lea latter two, .NET and JVM being “managed” platforms with byte code.
In all cases, you can expect top of the line performance out of the generated code. In particular, I want to make the point that the difference between “native” and “managed” often gets over-exaggerated. In our experience, well-written .NET code, for example, will run as performant as well written code compiled “natively” for the CPU type/OS. it’s a misconception that managed code runs slow and “interpreted”, really
We don’t do any comparisons or benchmarks for that ourselves, but for the Apple/Cocoa platform, I would expect code for our compiler to be faster and actually be “more native” that Apple’s — especially when interacting with Cocoa APIs (as most Mac or iOS apps are won’t to do eventually ;).
Apple had a pretty scary talk about Swift performance issues at WWDC, (iirc) last year…
FWIW, the difference there should be marginal, as in the end it all goes into the same syntax tree and its the same code — no matter what syntax you used. That’s for “comparable” code, of course.
Perhaps I should write the VM for my toy language in C# with Elements rather than Swift? Do you have an opinion on this? Presumably it doesn’t matter whether I write in Swift or C# if using the Elements compiler as it will be translated to the same IL anyway?
We essentially compile all our languages for the Objective-C runtime, was if they were written in native C/Objective-C.
Apple Swift is an entirely different API ecosystem sitting on top/parallel to the Objective-C runtime. For example, every time you pass an Swift string to a Cocoa API (or vice versa), you incur a conversion cost.
The ghost of the talk was “review every line of code that hands stings and talks to Cocoa Apis carefully. Your naive use of the APIs will most certainly be dog slow, but even off you go out oof your way to, say manually convert strings back and forth as needed, changes are tis gonna suck”.
This is of course a bit hyperbolic rephrasing, but thats what it boils down to.
They had trivial looking code samples that had me sit there like .
Unfortunately I cant find the right vide right now :(. I’ll keep looking for it. might have been 2018 or even 2017, not sure.
Mind you, this is talking about Apple Swift.
Correct. minute details aside (maybe, if even), you won’t be able to tell from the IL whether it was written in Swift, C#, Oxygene, or even VB, if its compiled with Elements. Pick the language you prefer writing code in best.
I’ve just done a quick test on a deep recursive Fibonacci function using Swift with Elements vs Xojo both as console apps and Elements is an order of magnitude faster.
For all fairness, I guess you should be aware that even though the language syntax is the same, the supporting RTL would be different, especially if you use Swift/.NET for Windows development. So I guess you won’t have 100% code once, compile everywhere.
Elements RTL should cover most non-UI, non-fancy-system-services areas, though — and i’d be happy to get feature requests for more areas to cover in RTL.
.