Multi Core CPU App guidelines


Any example on what is the best way to start here ?

I found something on the Xojo blog related to Supporting Multiple Cores written by Norman but unfortunately no example.

Required platforms , Linux (Debian) and Mac OSX . on MAC it might be simpler as the helpers you compile you can keep them in the resources folder on the main app for deployment as they are “single file” but what about on the Linux and why not, on Windows where you have the app and the libraries. Is there a way to share libraries so that we don’t have same library multiple times ? example Main App and 3, 4 helpers, the helpers being a terminal app maybe they will have same libraries but having them stored into the Main app Resources folder that multiply the library files which are on each app .

More examples on this and optimization would be great.

Thanks .

Thomas Templeman has a multicore project

You might also find some useful info in this thread

I started that thread!!!

In any case the lack of adding things that help give us more power in a approachable manor with less work, is why I said in the wishlist thread I have not been excited about new Xojo features for years (for me desktop is of primary interest) …

This area certainly could have been one such thing … AND would have been applicable to every type of platform as even mobile is multi core these days…

But such new features that make sophisticated techniques/capabilities more approachable are the type of features that got me excited, as they enable me to do things quickly that usually would only be done by very experienced full time developers… That type of vision is what it seems Xojo inc has lost now that I think about it now that focus is more platforms and more strictness.

Back in 2008, after he had left REALSoftware, Mars Saxman had a blog post where he talked about how he would have wanted to approach this if he had stayed. He described what I had in mind but he had the vocabulary/knowldge to express it much better than I could, when I had the discussion with Norman (who seemed to miss the essence of what I was saying) many years ago.

It is a (very) high level description about how to create a general purpose framework to support helper apps… Outside of integrating it into the IDE in single project, it points out how we could create some general classes to help with this (of course it would not as simple or elegant an API if Xojo inc did it with under the hood support).

I still think when they were rewriting the IDE (never mind creating the new framework at the same time) they missed a HUGE important opportunity to deal with multiple cores that would have payed many long term dividends.

Mars wrote:

[quote]I had a plan for multiprocessor support in REALbasic. If I had stayed on with REAL Software, my solution would not have been to add a “PreemptiveThread” class in parallel to the existing “Thread” class, but to implement something completely different. A new project-item type, which we might call “Subprocess”, would have allowed you to effectively embed a little console app into your larger project. Creating and invoking a new instance of this class would spawn off a subprocess, which the OS kernel would then schedule on any available processor.

The limitation, of course, is that this would genuinely be a separate process. It could use the same classes as the host app, but none of the same object instances, and none of the same static/shared variables. Instead, you’d send data back and forth, as though on a socket: each subprocess would be automatically wired up with a pipe-style communications channel back to the host app. Some basic serialization primitives would let you send the contents of arrays, dictionaries, and structures back and forth, triggering an event in the receiver. This, I think, would have directed people straight toward the best solution for multiprocessing, instead of giving them primitive, low-level tools they’d have to use to build their way up from scratch.

Bold emphasis is mine…

  • karen

Yep - we call that IPC and we’ve been doing it since before multiple processors were a thing. You should have seen the faces around my office when we received our first Corollary Systems 2 CPU box. Back in the 386 days, BRU tasks would consume 30% or more when running as a pair of tasks processing the filesystem data. When that second CPU appeared (SCO Unix), we watched the numbers drop to below 10% on each CPU thanks to the task manager built into SCO.

Today, I achieve similar success in RS/Xojo by using the Shell class and external helpers. The Shell DataAvailable and Completed events, and the IsRunning Boolean give me similar abilities to those days.

My point is that Xojo which is supposed to be an accessible object oriented RAD tool that should provide a framework to take care of a lot of the mechanics of doing that…

Many of use Xojo to abstract us from a lot of the details (in an X-platform way ) so that we can spend more of the time writing code that gets at the heart of the problems we are trying to solve with our apps, rather than having to build a road we need to get to the point that we can do that.

Lots of people need the same roads to get to that place for very different apps… that is the type of thing i value most because it frees me to concentrate more on my specific problems, rather than on mechanical details, if you get what I mean.

  • karen

If I have followed this correctly, Norm has been saying forever
‘Xojo isnt about to give you the ability to launch a thread and have it use a second core, due to not being able to share memory and other stuff’

The advice is : find a way to send data to another app, and watch until it has ‘done its stuff’ with the information.
And the problem with writing such another app is that it requires its own set of libraries and resources.
Whereas if it could use the same libs and resources as the ‘parent’ app, at least we could keep deployment size down a bit.
That should have been possible ‘easily’ on Windows, since the libs and dlls are all external to the exe
On the Mac, the bundle nature of an app would tend towards having bundles of bundles, which is nasty.

I totally agree. I was just sharing a memory and then presenting how I mimic that behavior within the realm of what Xojo can provide today.