Gan's Runtime & Script Interpreter

[Gan]

Gan's Runtime Cross-Platform Video




Magic? Sorcery? Computer wizardry?! No, it's Cocotron.

Cocotron allows Obj-C and Cocoa to be compile for Windows. From a mac. From inside Xcode. With 1 click of a button. Impressed?

Cocotron was a major headache to set up. It's still a young open source project, working to duplicate the Cocoa functionality for windows. Much of Cocoa does work on windows but bugs still exist and some functionality isn't made yet. There are plenty of programmers working on this project and so far it looks great.
Once the setup was completed, compiling and using my program on windows was a breeze.

This alternative for cross compiling has many advantages:

• Only need 1 source for your project for Mac and Pc and even Linux.
• Most of the time taken is to set up Cocotron and make sure your program's functionality works on both platforms.
• Much faster than recoding in another language.

Disadvantages:

• Headache to set up.
• Not all Cocoa features work, or work correctly. It's a work in progress.
• Lack of maturity in the project, may not be user friendly.

Gan's Runtime Mac Executable
Gan's Runtime Windows Executable

So this runtime can compile for mac and pc, fairly nicely(it works on both). Now what?
I have no idea.
Any of you guys have any ideas of what to do with this?

[x]

Wheres my credit for telling you about this  

And I still think you should make a token compiler for it.

[Telstar5]

94% CPU usage for 1 line.

----> http://oi54.tinypic.com/14j3f52.jpg

I think I need to lie down.

[GMG Mike]

Could be an inefficiency in the way REALbasic maps methods to the stack/heap/however it organizes it. C is know for being monstrously efficient at that sort of thing, and Objective-C is a superset of C.

SilverCreator uses REALbasic and this will never change. What would be beneficial to SilverCreator is to figure out the particular inefficiencies, and recode around them.

Or we can just be lazy, and wait for LLVM.

[Gan]

@Telstar
There's actually 5 lines in the start and 5 lines in the timer methods. They just weren't showing cause they were bugging out on me. 95% CPU is due to the 100 sprites moving on screen being drawn at 60 frames per second. Yeah, very inefficient. Would help tons to switch to OpenGl.

[Telstar5]

Why 60fps for something that isn't moving? Sure, I see the point of being able to have 100 sprites on screen at the same time, but isn't 60fps a bit... overkill?

I'd fiddle with the runtime myself, but it's eating system resources whilst idle. That's probably Cocotron, though.

[Gan]

Why 60fps for something that isn't moving? Sure, I see the point of being able to have 100 sprites on screen at the same time, but isn't 60fps a bit... overkill?

The timer is automatically set to 60fps and it also controls the updating of the screen.

I'd fiddle with the runtime myself, but it's eating system resources whilst idle. That's probably Cocotron, though.

Yeah, Cocotron isn't entirely safe at the moment. Best to try the mac version.

[GMG Mike]

SilverCreator does not update the screen 60 fps by default.

At first, the screen was updated every time you moved a sprite, but this was found to be inefficient if you needed to move 10 sprites. So that's why we have the extra boolean at the end, with your last sprite move omitting the boolean and causing the screen to update.

You can also choose to use the boolean with ALL sprites, and then use UPDATESCREEN in a timer.

[Telstar5]

If Cocotron is that unstable, I wouldn't rely on it for compiling Windows binaries. You'd be better off using two separate source codes and keeping compatibility with the end-user syntax. Or use another cross-platform library like Qt.

[Gan]

To stabilize Cocotron it requires me to use my program and dig deep fixing stuff. Then what I fix I should send off to the Cocotron to post as a patch.
Then it's a win-win for all.
They say it takes less time to stabilize your program then to recode it.

I just can't wait till Cocotron becomes pretty much complete, fast, and safe. But that'll take a while, it's just an open source project being lead by 7 main programmers.

I think I'd like to try other cross platform alternatives but I'd very much like to stay within Obj-C and Cocoa.

[Gan]

Hey Mike I did a Obj-C vs RealBasic speed test:

Realbasic Speed Test Source

Obj-C Speed Test Source

Language Speed Test

• RealBasic: 215 milliseconds
• Obj-C: 3 milliseconds

Obj-C is 71.6 *faster than RealBasic

Scripting Language Speed Test

• SilverCreator: 33 ticks
• Gan's Runtime: 2.5 ticks

Gan's Runtime is 13.2 *faster than SilverCreator

So what's my point?
Well if we do further ratios...
According to this data... If RealBasic had the speed of Obj-C, SilverCreator would clock in at:
33 ticks / 71.6 = 0.46 Ticks.

If Obj-C had the speed of RealBasic, Gan's Runtime would clock in at:
2.5 ticks / (3/215) = 179.16 Ticks


Conclusion
If my math is right and language speed was constant, then if SilverCreator were written in Obj-C exactly how it is then it's be about 5* faster than my runtime.

What does it mean?
If this data is correct, SilverCreator is more efficient than my runtime. It just has RB slowing it down.

[x]

Languages are never consistent in their speed for different operations. Although I agree that Obj-C would be much faster than REALbasic, but I'm not sure thats a fair margin. Can you post the exact code you used? Maybe Mike could optimize it better for REALbasic, than you can. Plus I would like too know.

[Gan]

The download links are below the images.

[Telstar5]

I think I'd like to try other cross platform alternatives but I'd very much like to stay within Obj-C and Cocoa.

Why? Other than because it's supported by Apple. In the long run something like Cocotron is never going to be as fast on Windows as it would be if it the applications compiled using it were written using the Windows API, or something that is cross platform by design and is already very mature.

Edit: I mean, don't get me wrong, this is a fantastic app and a great achievement, but I'm just saying you could take a lot of the pain and headaches out of cross-platform by trying something different.

[GMG Mike]

Gan actually compiled the Cocoa tests, while he RAN THE REALBASIC TESTS IN THE DEBUGGER

RB apps in debug mode are slower.

The entire test above is flawed and should be thrown out.

Here are my tests. Both apps are 32-bit Intel. Both apps are compiled.

RB: 70 ms
OBJC: 3 ms