Right - as I said I recall when you initially did this and the various questions and the reason you did it this way.
There may be others whose needs are similar.
I know that John Balestrieri used a different model for his election night graphics generator - but it was still largely main app + lots of helpers maxing out a LOT of machines. It was distributed across machines - not just cores. http://www.tinrocket.com/2008-ap-election-graphics-software/#more-660
And Peter Stys solution is a main app that portions out graphics jobs using shared memory for the ultimate in speed. But it too is a main app + helpers.
So there are many ways to architect things to max out every core on a single machine or all the cores on lots of machines.
I think multicore is a big requirement given that datasets are getting bigger and clock/RAM access speeds will not rise much anymore. I spent a lot of effort parallelizing CERTAIN functions in my app (as folks correctly say, not all functions lend themselves to concurrency). My solution, perhaps not the best one because I’m anything but a professional programmer, is a master and any number (1 per core) helper processes launched as faceless console apps. Debugging is hard especially when you have 24 helpers running in parallel, however RB’s/XOJO’s ability to (almost magically) simultaneously debug the master and one slave is a godsend.
What made this all work for me and my large image data is ability to use shared memory thanks to Christian’s MBS shared memory functions (also gets around the 32 bit limit as shared memory lives in the OS’s 64 bit world, so long as you don’t map in more than 4GB into master/slave at any one time). This obviates the need to actually copy/send large amounts of data between master/slaves as they all share the same Ptrs. IMHO this may be the ideal way of interprocess communication if such a mechanism were ever built into XOJO.
Sorry to bump this thread, but it’s something I’ve been thinking about for the past couple of days.
I’ve written an application that does a lot of analyzing of files, it the data set is small it’s instantaneous, however throwing a large dataset at it, can make it take some time.
A simple progress wheel continues on spinning even if the application is really busy; however I’d like to display an actual animation; which then get choppy and ends up looking like shite. So I was thinking about a means of utilizing multi-cores.
I had pretty much settled on the idea, of simply spawning a new instance of the main app and instructing it do the lengthy task, then using IPC and IFF as a means of communication. The reason why I favored this idea is that I thought it would be easier to debug, as it’s all in one Xojo project. I do realize that while this space efficient on disk; it’s far from memory efficient.
I’ve done projects in the past where we’ve used C++ plugins and helper applications, and I always found debugging those a PITA as sometimes you’re not sure if the bug is in the helper or the main application, and it means maintaining two sets of code.
I was mighty pissed when something changed in Xcode and an older helper application would no longer compile and I didn’t understand the error messages I was getting.
The current project is simply to have two instances, one GUI and one processor; however if I can pull this, there’s a future project which might invoke multiple instances (to fill all cores).
Right now, I’m to suggestions and would like to simply discuss all possible options.
Thanks Norman…
Apart from having to manage separate projects (unless there’s some magic), the other concern I have for this is that the helper would also need it’s own Libs folder.
Could I combine the libs into the main apps Frameworks folder (eradicating duplicates) and then use a symbolic link either for the “Libs” folder or for each library within the libs folder?
You can’t place an executable in the Contents folder, if you want it to be code signed or approved on the App Store. So I’d have to create a relative symlink (as hardlinks are absolute), then the helper can be in the helpers folder. I guess I’m simply going to have to try!
I contemplated use a symlink to point the rbframework.dylib to the XojoFramework executable; but… They’re not the same and rbframework.dylib links against libraries that the XojoFramework doesn’t.
But at least any duplicate plugins and such should be able to be shared.
(I’ve overseen some posts in the middle so please be kind if this is already said somewhere)
Reset to the beginning:
I see three basic problems:
Norm said (and btw. xojo documentation too) threads share the same CPU and so it may degrade execution speed because of switching, additional checks, properties etc. (though this is not a problem, these are just the rules)
Splitting an algorithm in multiple console helper apps lacks the possibiliy of sharing classes, properties etc. Everything has to be transported “in a pipe” from core to core by file, database, network (IPC?) .
Debugging and finding flaws between several helper apps and UI. Sam brought up that lib files are spread over different places. You have to compile several apps in multiple IDEs switching back and forth…
Right? So in the initial post Karen just wanted a better way to integrate these two approaches within the IDE. I’ve read the comment of this former RB guy and still do not know what he meant with “radian”. But as far as I understood Karen is just asking for a better implementation to deal with helper apps. And Sam brought this up because he’s looking for a better solution to trace down bugs.
So wouln’t is be great to …
… enable additional Compiler Settings e.g. where to put shared framework libs - perhaps editable paths?
… mark threads kind of “isolated” and let them then run in different cores without sharing same ressources? To maintain backward compatibiliy and error tolerance the normal behavoir on missing cores would be that it would remain in the same core.
How do you think about these to improvements? Norm? Sam?
Okay; so I can’t use a symlink to get the helper application to utilize the XojoFramework instead of rbframework.dylib. The helper application freezes on launch.
Multiple lib folders are only part of the equation, one main app with one helper application is 20mb on disk. Where as multiple instances of a single app, halves that to 9.3mb. I’d really like to avoid having to have multiple copies of the same dylib/plugin also, thus doubling the disk usage.
The other concern, I’ll explain below.
@Tomas Jakobs Tracking bugs is certainly part of it and so is sharing code, resources and such. Right now, what I’m looking for the easiest way to create an application that can do some heavy processing on one core and continue to provide a smooth animated GUI on the other core. I haven’t even gotten as far a communication method between the two processes.
I’m toying with designing one only application (and thus one project) and having the main application launch another instance of it’s self to do the heavy work, launch parameters would govern which one if the nice GUI and which one does the donkey work. IMHO, I think this option is the easiest to work on as it’s all one project and one executable.
The alternative is the helper application solution. The advantage is more focused applications that handle specific tasks. I was going to say smaller and lighter, but if anything console apps seem to use more disk space than GUI apps.
Both ways can lead to debugging issues, I would think that a single instance application would be easier to debug, but as I’ve not tried it yet, I can’t be positive.
Also sharing code is not so much an issue thanks to external objects.
More thought and possibly experimentation is required.
In the windows environment I typically don’t combine the libs folders. Keeping them separate has the advantage of not having to build all the helper apps every time I want to distribute my app. What the article @Sam Rowlands refers to didn’t mention is that it is very unsafe to use the dll’s of projects compiled with previous Xojo versions or use new dll’s with older versions (probably because that was the first version with this new technology).
I guess it comes down to where your customers live. My customers live in a place where the Internet is fast & volumes are relatively cheap (or at least we’ve become accustomed to the cost). An extra 100-150Mb per app download is nothing, but I’m sure that’s not the case everywhere.
I do understand the want to minimize the footprint of an app. Prior to 2000 I was fixing y2k bugs in COBOL apps with a page size of 64k (56k usable). That taught us how to be frugal believe me! This whole process just isn’t relevant today with modern technology, disk sizes and memory availability.
[quote=249675:@Christian Schmitz]MBS Plugins come with an example for a GUI app which also is a console app.
Especially app.ArgumentsMBS helps to get arguments from command line cross platform.[/quote]
Thanks for the info Christian.
Ah yes… This is also a good point, we can combine all the libraries, but should we… Unless the application and all of it’s helpers are re-built for each release, it’s potentially a crash fest waiting to happen.
This is certainly something that I think about a lot, I spend a lot of time trying my best to use as little space as possible. It is indeed not so necessary; but it’s something that I believe in so strongly.
I was forced to re-write an application to make it compatible with El Capitan, and in the process the application size dropped dramatically, I attribute most of that to Xojo’s 64-Bit compiler. We’re talking going from 27.9mb down to 5.9mb.
Michael, I know it’s been a long time; but I wonder if you could share (in general) what kind of issues you came against using the one-app-to-rule-them-all method?
Caution! In Windows AD networks often software policies are preventing this behavoir if the app is located outside regular program folders. Right now I have a customer using a known banking app in Germany (SFIRM) which is exactly doing what you’re toying with. But it’s moving its exe helper files into to TEMP folder (or AppData) during runtime and starts it from there. Windows Policy is blocking this cause this is the same behavior Viruses, Cryptowall etc. also do (putting the “Payload” in the temp folder and starting it from there)
Agreed, debugging a helper app is a pain in the behind. But conserving space - just a couple of MBs - isn’t really important nowadays.
As far as I remember the location of the to be debugged app was a problem. The helper app is supposed to go into the main app. Therefore I had to have several modes for the main app so that the helper app could be recognized. But you can always run both main app and helper app in the debugger at the same time.
Interesting… I wouldn’t be doing that, simply forking another instance of myself (where the app is currently located) and passing in some launch arguments to dominate the new instance… I shall call it a clone.
Yeah I can see how this might cause some security apps to panic.
It is turning me off thou… Harder to debug and adds an additional 10mb per helper (at least)… I think it’s more space efficient to build multiple desktop apps, at least you can use the GUI while debugging and then with the right plist entries you hide the GUI when you ship.
If the libraries can truly be shared (not just on disk but in memory also), this might actually be better than console apps…
It seems like I need to do some additional research into why creating new instances of myself is a bad idea or hard to debug.