Multi-core usage information for Xojo

The 2nd most popular feedback on Xojo’s Feedback app is a form of task concurrency or preemptive threading. I know that this discussion has been beaten and beaten and beaten to death; the problem is that is presents a ceiling to what’s capable in native Xojo. Sure some of us are capable of utilizing other tools to work around this, but that doesn’t make the ceiling on Xojo’s capabilities any less real; if anything it makes it worse.

I’d like people to collectively list what they’d use this functionality for. I feel that Xojo being able to see what we want to do, will help them make the best choice in technique moving forwards.

First up; I’d like to run the following processes as a foreground task soaking up as much power as possible.

  1. Read / Write Uint32s, Uint16s, Uint8s or Singles from a memoryblock/Ptr (which contains pixels values) and apply some basic math to these values (process the pixels).
  2. To be able to read values from multiple memoryblock/Ptr and combine them into another memoryBlock/Ptr.
  3. Building a CLUT based upon a dictionary of settings, a channel location, a Gaussian range, and of course the actual channel adjustments to make. CLUTs don’t take long to build, but when you’re trying to provide live feedback of adjustments to the CLUT, it’s a horrible experience right now.

I’d also like the ability to run tasks/threads in the background, either using all but one core or just one core (you know to keep energy consumption down). This way the application can do a long task, while still being fluid, slick and oh so buttery smooth. Perhaps the user could even ask the app to do another task at the same time.

  1. In App Wrapper; I’d like to be able to run app diagnostics in the background while the user is configuring their desired settings for the wrapping process. This way I can report potential issues, before we even start wrapping.
  2. I’d like to be able to do the actual app wrapping on a background thread, so that the App Wrapper UI is buttery smooth while wrapping, and the user can do other tasks, like preparing another wrapping session or continuing to upload their already processed apps to Apple.
  3. I have two other apps in development where again, I’d like to be able to farm off their complex processes, completing in the best time possible, while the UI isn’t “Frozen” during the task.
  4. I have a prototype for some video editing tasks, I’d like to use one thread to read the frames, stacking them up in memory, another thread then takes those frames and processes them, stacking the rendered frames elsewhere, and a third thread that takes the processed frames and writes them to disk. A fourth thread, could take a frame of the processed stack every once in a while and update the onscreen preview. As it is right now in native Xojo, I read, process, write; every once in a while, I also update the preview on screen. Whereas I could be processing frames while reading or writing, or reading/writing while processing frames, or doing all 3 while the onscreen preview is being updated.

At the very least I would need memoryblock/Ptr options and math functions. Declares would be second on my list. Dictionaries and folder items would be high up there also. NSTask/Shell is also needed for some tasks.

I look forward to seeing what you’ll be looking to do when we have this ability.

@Sam Rowlands — I think you are idealizing preemptive threads. You cannot just write some piece of code and divide the work for 4 threads. You need to actively dispatch the work between threads, control access to data shared between them etc. That is a lot of work to do and it is not really easier than dispatching the work to helper processes.

I will take your point #4 as an example: you would like to separate different steps into different threads but the steps are vastly different and execute at very different speeds:
1. reading frames will be fast so it will eat up memory very quickly
2. processing frames will probably be the slowest task (depending on what you do)
3. writing frames to disk will be quite fast but not as much as step 1 and it can be limited by the drive’s speed
Eventually, your 2nd thread will use 100% of a core power while the others will spend most of their time waiting.

I could use multiple cores to

  • crunch numbers (statistical data from large data sets)
  • manipulate and analyse images
  • create scientific simulations
  • maybe develop games

Multi-threading using multiple cores is not rocket science. You learn how to do it quite at the beginning when you study computer science - at least we did it in an introductory course to object oriented programming in Java. So using multiple cores would be a feature many developers already know how to use and surely would also love to use in Xojo.
I think using helper processes causes more work for the developer, especially debugging can become quite complicated.

1 Like

I think the main benefit for us would be the ability to run several different tasks independently without blocking each other or the UI.

Pre-emptive threading would be utopia as it would remove a lot of restrictions and work for mobile targets but there are several other things Xojo could improve upon to help with performance & concurrency.

  1. Improve the performance of FolderItem.
    The implementation seems very inefficient. There appears to be no property value caching and from profiling the Win32 API calls generated by the framework, there appears to be a lot of repeated calls.
    We had a scenario where basic FolderItem calls would block for several seconds when accessing files on a customer’s NAS. We replaced FolderItem with some declares and got in some cases a x10 improvement.
    If this was better there would be less blocking of other threads.

  2. Make more of the framework non blocking when executed inside a Xojo thread.

  3. Allow multiple targets (for example, Desktop & Console) to be built from the same project.
    One of our projects has been built in such a way to allow horizontal & vertical scaling by offloading the processing to long running helper apps which communicate via TCPIP. Everything except the UI code would be shared across the Desktop & Console apps. At this present time we have decided not to progress the scaleable version as there is no way to simultaneously develop, test & maintain both versions from the same source code.

1 Like

Don’t get me wrong, as I like programming in Xojo, and there are two main areas where I currently use other programming languages because Xojo does not have multi-core functionality:

  1. Graphics - There are continuous problems with flashing, blinking, studdering, and other issues with drawing in Xojo. When I program graphics using Declares, then there are no issues - and this takes considerably more time to program. Using the native Xojo language in Windows causes me to create too many work-arounds. I can use any of the major programming languages and not have this issue. I am not sure if it is because Xojo does not use multi-core or not, and this might be a work-around to have respectable graphics.

  2. Interrupts - When programming hardware, interrupts are needed to accurately get feedback from transistor-transistor-logic and sensors. Multi-core functionality would allow the tedious monitoring of a sensor to be performed without interfering with the main program logic. Xojo doesn’t have this ability, so I usually use the other major programming languages. Main operating systems that I use are Windows and Linux (Ubuntu and Raspbian).

Would I like to continue to use Xojo for these applications? - absolutely yes. For now, this is not an option and must use other languages due to this lack of functionality. This is not an easy task to make the programming language multi-core safe, which is likely why the request has been open for many years.

1 Like

How about a feature request for a multithreaded XojoScript?

I could at Threaded support for our JavaScript engine…

Sam,
You and I have discussed this in the past. And yes, I fully concur with your wish to have a less complicated way to use all the cores for compute-intensive tasks. Like you, large image processing is what I need this for.

Christian M: you say “Multi-threading using multiple cores is not rocket science.”. Maybe not, but “I think using helper processes causes more work for the developer.” I know of no other way to write MP code in xojo other than helper processes. If you have a way, please let us know.

I solved this issue with helper processes and MBS’s indispensable shared memory functions. To have a built-in simpler way of writing MP code within Xojo would be great. But like Sam said, this has been beaten to death.

I have a scenario I’d like to implement: I have a lot amount of data in dictionaries, plus array-based lists of indexes to that data. Each index needs to be updated as quickly as possible as the user makes changes to the data, but this can take a significant amount of time (there are at least 70+ indexes, 3 or 4 or more of which can require updating with each user edit). Being able to use a separate core for each index’s updating would speed things up tremendously.

I’ve tried using threads, but with only one core there’s no speed improvement. And I haven’t found a workable way to use helper apps to read the shared dictionaries. My hope is that would be easier with a built-in multi-core implementation.

1 Like

You may want to take a look at MBS’s shared memory functions or ast @Peter Styts puts it in the previous reply:

Perhaps Peter will expound on what he does, but MBS also has some example code linked from this page.

[quote=476354:@Douglas Handy]You may want to take a look at MBS’s shared memory functions or ast @Peter Styts puts it in the previous reply:

I solved this issue with helper processes and MBS’s indispensable shared memory functions.
Perhaps Peter will expound on what he does, but MBS also has some example code linked from this page.[/quote]

I use MBS all the time, but somehow it never occurred to see if they had something like this. I’ll check it out, thanks!

Hello Peter,
unluckily I do not know a way to use multiple cores in Xojo apart from helper processes*. That is why I would vote for implementing support for parallel multithreading in Xojo. (Of course I have not the slightest clue how difficult it would be to add such a feature to Xojo.) Thanks for mentioning the MBS plugin functions that can use multiple cores, maybe there is something I could use in the future.

*Helper processes: In complex applications one would have to create not one but several different helper apps (for example one for analysing/manipulating images (a couple of instances running at the same time), another one for uploadung the processed images to a database and adding some metadata to the database etc.). Also one needs to implement some sort of messaging between the main app and the helpers. This is probably harder to develop and to debug compared to using an other programming language I know which has support for parallel multithreading.

1 Like

[quote=476341:@Christian Schmitz]How about a feature request for a multithreaded XojoScript?
I could at Threaded support for our JavaScript engine…[/quote]
Hi Christian,
I apologize that I may not have explained the intention of this thread clearly. I’d like to gather evidence for Xojo, on what we intend to do with concurrent processing, in the hopes that it will give Xojo enough evidence to choose a mechanism that will satisfy our needs.

We can talk about different ways to accomplish a potential solution now, but can we please do that in a separate thread.

I am sorry to be nagging, but I really want this functionality in Xojo and I’m trying to aid Xojo (in ways that I might be able to do) to help them be clear as to what direction they should be headed in.

all this requires a thread safe framework and runtime
something that has been true for many many years
without that nothing can work

1 Like

[quote=476364:@Norman Palardy]all this requires a thread safe framework and runtime
something that has been true for many many years
without that nothing can work[/quote]
Understood, and I can’t change that, I can only hope that by aiding Xojo to formulate a plan of attack, it will change.

[quote=476363:@Sam Rowlands]
I am sorry to be nagging, but I really want this functionality in Xojo and I’m trying to aid Xojo (in ways that I might be able to do) to help them be clear as to what direction they should be headed in.[/quote]

For many years it has been obvious that the future will be (has become) more cores rather than clock speed for improving hardware performance. It is obvious that any processing intensive app (as well as servers!) need to be able to use multiple cores to get teh best (or in some cases just decent) performance from the hardware…

Helper apps are a complex, hard to use solution that becomes even more complex with the security features of each new OS release.

Xojo inc knows all this but seeming has decided:

  1. They don’t have the resources to to make the framework thread safe

  2. Only a small percentage of Xojo customers REALLY need it so its really not worth the effort- and most of those that do need are advanced user that could do helpers on their own

  3. #2 apparently also means that see half measures are not worth doing

I agree with #1
I think #2 is a minority but is a bigger minority than they realize and will keep getting bigger
I think #3 is their biggest mistake given #1.

Being able to have helper apps integrated into the same project as the main app, a providing high level a API to high speed/efficient communication between helpers main app with a lot of copying (aka shared memory) , and provided integrated debugging the whole mess, together would make helper apps a heck of a lot more approachable to the typical Xojo customer.

Given #1, I think they NEED to build in easy to use X-Platform helper app support, and IMO need to do it soon.

1 Like

I dont think there’s any lack of clarity about how it would be useful or what people would use it for
The IDE could make use of it loading projects, saving projects, compiling plugins etc

The trick is while its one small statement, "make the framework thread safe"its a massive undertaking to actually do it (and prove it IS thread safe) And then to maintain and advance the framework without breaking that thread safe guarantee

Making Xojo script use multiple core (ie each script can run on a different core or something like that) is more plausible - although not quite as useful I get that. The existing sandboxing already ensures that no one thread can directly and deliberately or inadvertently corrupt the global state or another script. Thats roughly the same kind of guarantee you need for preemptive threads to NOT be impossible to work with and debug.

The other alternative to preemptive threads is making it a lot easier to write helpers
THat would IMHO be a more likely target since each helper can be simply debugged and doesnt require the huge engineering effort required to make preemptive threads possible (which I’m not convinced IS necessarily THE answer for many tasks)
IF we could write a “helper” process and simply shuttle data to it and get access to whatever results that help generated simply then would we care about whether its preemtpvie threads ?

To be clear, the ones I mentioned are for sharing memory, which potentially be beneficial for sharing data with helper apps. They do not themselves enable multiple cores. However, Christian mentioned the possibility of multithread support for the Javascript engine but I don’t believe this exists in MBS today.

Thomas Tempelmann had shown in Munich that a thread-safe approach IS possible in current Xojo. As callback and as background process.

Well, I’ve tried yesterday and got two new functions for JavaScriptEngineMBS class:

  • EvaluateMT
  • CallFunctionMT

Both will run the work on a preemptive thread. If you call Print, Input or a delegate function, they’ll dispatch it to the main thread and wait. So you can use it to run JavaScript with preemptive threads if you like. And I’d expect Xojo Inc. could do the same with XojoScript to do it multi threaded.

What are competing programming environments doing in this area?