Take advantage of your multi-core processor- Not as easy as it could be

On the Xojo blog Paul Lefebvre posted an article about using multiple cores using console apps. As most here know, Xojo apps, even with threads, run on only a single core and most machines these days and multi-cores. Paul provides an explanation and example code.

But while it is doable with Xojo, it is more complicated that it should be for something so important for the future…

IMO it points out a HUGE opportunity that was missed in the IDE redesign…

A few years ago i exchanged some posts with Norm (which he may not remember) about the possibility of integrating console apps into a desktop project as helper apps so it could share class and be managed as whole a single project (instead of multiple ones) with easy, efficient and safe ways provided by the framework to share info between helper and main app… I was not very clear in my terminology or explaining what I was trying to say … and it also turns out not original in my thoughts either … A former REAL employee (Mars Saxman) had already thought through how he would have done it back in 2008:

http://www.redecho.org/2008/12/16/concurrency/

Building the new IDE would have been a GREAT opportunity to add in this type of explicit support of concurrency into framework and the IDE to create a seamless whole instead of trying to bolt it on some day in the future … and I was disappointed when it was not there…

Paul’s Blog post reminded me of that.

The big problem is easy, efficient and safe ways provided by the framework to share info between helper and main app

The importance of concurrency isn’t about past, present, or future. It’s about algorithms that can take advantage of it. If you don’t have algorithms that are amenable to concurrency, there’s little point in the exercise. If you have such algorithms that are amenable to concurrency, you pretty much have the same issues whether the sub-tasks run as (presumably pre-emptive) threads in one app or as multiple distinct processes on a computer: split up and schedule the tasks, run the tasks, coalesce into a result. The more messaging that needs to take place between subtasks, the worse a candidate for parallelization your algorithm was. Many problems just don’t lend themselves to parallelization. Think 9 programmers trying to make a baby in 1 month.

My reaction to them doing something like Mars described… Multiple targets in a project would be wonderful. Heavily coordinated as a scheduling method for parallel algorithms would be fun to play with but probably need to be reimplemented for any specific problem.

[quote=22841:@Karen Atkocius]
Building the new IDE would have been a GREAT opportunity to add in this type of explicit support of concurrency into framework and the IDE to create a seamless whole instead of trying to bolt it on some day in the future … and I was disappointed when it was not there…

Paul’s Blog post reminded me of that.[/quote]

I agree Karen, there were many missed opportunities to GREATLY improve the functionality of this product and they’ve known we’ve wanted more modern features for years. I guess we just have to continue to wait or use other tools.
I would think since they’ve created a web app product multicore support (and 64 bit support) would be very important to them, more important than giving the IDE a new face.

I feel the problem is Xojo doesn’t have multicore support built in. If it did developers wouldn’t need to create and rely on separate console apps. And what is wrong with encryption for communication?

The trends in web server architecture run quite contrary to such a conclusion. And you’ve also got the problem of a developer base that continues to want to “negotiate” over framework thread safety. Pre-emptive multi-tasking would be a disaster. Even done right, not many developers would get their heads around it correctly in any way that would prove beneficial.

[quote=22848:@Mason Mack]
I feel the problem is Xojo doesn’t have multicore support built in. If it did developers wouldn’t need to create and rely on separate console apps. And what is wrong with encryption for communication?[/quote]

This reply simply tells me that you don’t understand the issues involved in having “multi core built in” - its not just something you turn on and do. If we just do multi core with cooperative threads its pointless. So we have to do preemptive threads.
And as soon as we do that we HAVE to have a fully thread safe framework (so that’s one issue)
And then we have to make it so that when you’re code does something like the following in a thread it doesn’t generate the “wrong” result

 app.someCounter =  app.someCounter + 1
if app.someCounter = 1 then
   msgbox "hey we hit 1"

end if

You might look at that and think “well at some point it will hit 1” and I can certainly say that sometimes it will. And sometimes it won’t.
Say you have 2 threads (and it gets worse with more threads - so lets start with 2)
When you compile this code in each thread you might get a set of instructions like

 fetch app.someCounter into register
 add 1 to register
 store register into app.comeCounter
 check value of app.somecounter = 1
 jump to NO if not
     call framework msgbox method with "hey we hit 1
 NO :

(in fact its probably a lot more instructions for the CPU but this will suffice to show the problem)

So now we have 2 threads - thread1 and thread 2 that are both going to run this code
Thread scheduling is NOT under your control so the OS can switch from one to the other at any point - heck it could run both since we have multiple cores

So thread 1 starts (lets assume we start 2 threads when the app runs so everything is just initialized)
(t1 denotes what thread 1 is doing and t2 denotes what thread 2 is doing)

 t1 - fetch app.someCounter into register

hmmm os preemptive switch
t2 - fetch app.someCounter into register
t2 - add 1 to register
hmmm os preemptive switch
t1 - add 1 to register
t1 - store register into app.comeCounter (so now app.somecounter = 1)
hmmm os preemptive switch
t2 - store register into app.comeCounter (so now app.somecounter = 1)

now it wont matter which thread does the check it will NEVER be true

And because what I wrote is VERY high level compared to actual machine code it glosses over a PILE of other real problems (like trying to write to the same address at the same time, read from the same address at the same time and all kinds of other issues when all threads run in the same process)

Now the nice part of a helper app is - IT DOESN’T RUN IN THE SAME PROCESS SPACE !
Which means what ?

  1. your single app that could only currently take advantage of 2Gb of memory can use 4 6 8 or more because each process gets a 2Gb memory space to run in - ask folks who’ve used this mechanism and you can max out just about ANY machine available this way.
  2. debugging multi threaded apps is a serious pain in the butt because things are rarely repeatable. The illustration above might run completely differently the next time & you get the message twice - or once or never. With separate processes you can debug ONE instance at ONE time as a standalone program which is a lot easier.

[quote=22862:@Norman Palardy]This reply simply tells me that you don’t understand the issues involved in having “multi core built in” - its not just something you turn on and do. If we just do multi core with cooperative threads its pointless. So we have to do preemptive threads.
[/quote]

You misunderstood Norman.
Please explain to me where you think I said it was like turning on or off something?
Also show me where I mentioned the differences of thread types (cooperative vs. pre-emptive) and that I suggested using one or the other?

I never said it was something like flipping on or off a switch .
I wonder where you get these ideas from thinking I wrote them?

For a long time now there’s been a feedback report on this where it’s been discussed in more detail which I read a long time ago. So yes I do or did understand the differences between the thread types and the complexity of the situation but I don’t need to waste my time refreshing my memory by re-reading the details of the problem because it’s not my job to do that and I don’t have time to dedicate to things that aren’t critical to my life right now. I’m very busy with my own coding problems and my personal life :slight_smile:

What you should of understood from my post is that this is something that customers want and have wanted for years and so far no progress has been made towards a solution. I believe part of Karen’s point was instead of putting a lot of time towards an IDE that works worse than what we previously had, she, I, and others would of much more appreciated the energy spent on providing more important modern features like multi-core support, and other things.

There were complaints of the new IDE in beta testing. What happened?

For the other post that mentions server architectures isn’t really applicable here.
Why?

Because those modern tools are much more efficient and have much less draw on the server or desktop computer so running many multiple instances is not much of an issue when the choice was to not use multi-core support. That isn’t how xojo apps are. Xojo apps use a lot of ram and cpu so running many instances of them cripples the server’s ability in comparison to the other technologies. This problem magnifies with the more xojo instances you need such as in a server environment.

So the people running many WE instances (like Wayne) trying to make up for the lack of proper multi core support and other issues are losing a lot of server ability in comparison to modern architectures. Forum member Wayne mentioned he’s using either 4 or 5 servers to handle about 4,000 users. That’s more servers than other technologies would need. Wayne could probably use 1 server with alternate technologies unless all of those users are doing something highly intensive like real time chat and even still he’d be able to use less servers. He never answered my question of what those users are doing and nobody’s provided any performance tests so the assumption is fairly clear but inexact.

Norman I appreciate your responses but many times you seem to miss the point or say incorrect things in my opinion. Rather than create a side discussion I often let them go. For example in another thread recently I mentioned other tools have drag and drop layout ability and you replied something like “not like this they don’t.”
I have no idea what you mean. Not like what? How is Xojo’s drag and drop layout ability different than other application’s drag and drop layout ability?

Even though I’ve become more aware of Xojo’s web edition limitations and have been suffering numerous bugs I still may purchase it if the bugs get fixed because it still may fit my needs for some projects.

Norman you seem to have a personal bias against me and it comes out in your writing.

:slight_smile:

Wait, how do you know “no progress has been made towards a solution”? The folks at Xojo have said that part of the reasoning behind the new IDE is that will allow them to do things they couldn’t do with the old. Since they haven’t been specific, at least with me, how do you know this isn’t one of those things? It seems to me that you are making some assumptions here.

We want this for ourselves but it isn’t likely to show up as “preemptive threads” but more like Mars discussed as “Tasks” or “Processes” - mini programs. We’ve discussed how to achieve them and the issues surrounding them always come back to whether data moves between the main application and the “process” and if it does how. That’s THE biggest issue since it definitely has implications for what we do and how easy it would be for you to use.

If these are / were treated like small applications that you could had a constructor you can call to set them up with some initial values, then tell them to “run” and when they complete you have an event or some way to get the results thats one model. We’re not sure that’s the most useful to people as it literally would mean there is NO communication of intermediate results , progress, etc. between the “process” and the main application. And no reading globals, properties off of windows classes etc. Basically you hand the process a bunch of “values” and it does its thing.

For certain operations that might be useful. For others it would not.
For the compiler we could spawn off a handful of these to compile each item - which would make one portion of compilation quicker.
But it would not make linking them all together any faster as that still has to pretty much happen on one thread for now (not sure if the new compiler will change any of that at all but lets assume it won’t)

We are have discussed other models of interaction between the “process” and the main application.
The main issue comes down to how to handle the communication in a generic way so you could pass your applications objects (or at least their values) to the “process” in a way that’s not going to be horrible. Generically pickling & unpickling has problems (are they deep copies or not?) And what do you do when the process goes off calculates something and your main thread then changes the values in the object that the process was dealing with ?

There’s a whole bunch of issues. And, if you’ve written an app that uses helpers (which really isn’t that hard) you’ve had to deal with them already.

Saying this hiding behind a fake name deserves no further reply.
You won’t get any more from me.

[quote=22879:@Norman Palardy]
Karen Atkocius Building the new IDE would have been a GREAT opportunity to add in this type of explicit support of concurrency into framework and the IDE to create a seamless whole instead of trying to bolt it on some day in the future … and I was disappointed when it was not there…
We want this for ourselves but it isn’t likely to show up as “preemptive threads” but more like Mars discussed as “Tasks” or “Processes” - mini programs.[/quote]

That is what I was asking for…

For the general case I would think he helper being able to return intermediate results/ report progress would be important, as well as the main app being able to send messages to the helper… abort is an obvious one!

I’d suppose that would be a “kill” that would show up in the process as an Exception. As for intermediate results, it could just be simple types allowed, like integers or booleans, so that they can be copied for reading. Without knowing a thing about what I’m talking about, I’d imagine that would make things easier.

Still a lot of work since we have to alter the entire compilation process to create 2 applications rather than one & even for the simple cases write all the required framework. Honestly we just had way too much on our plates already to even consider anything extra.

The general case is much harder simply because of expectations and what you can do with other types like threads & timers that sahre some measure of similarity.
Say you have a “process” class in your larger apps list of project items.
Doesn’t it seem reasonable that in the code you write for that “process” or one of its methods that you should be able to access properties of the app class ? Everything IS in one project so why would you not be able to ? You can do it elsewhere like timers & threads so why not in a “process” ?
Or if you put one of these instances on a Window layout. Can you read the top left height & width properties as your code runs ?
Say like you could with a timer instance ?
The confusion about what can & cannot be accessed in the methods in the “process” would be VERY hard to explain. and hard to delineate in a way that would make sense.

These are things that we’ve discussed and you can see why “user expectations” and how to make this work since it would all be in one project is VERY important.

Right now because you have to write thing as 2 separate applications it’s very clear that you can’t read the app properties of the main app from the helper since they are two different projects.

[quote=22885:@Norman Palardy]Right now because you have to write thing as 2 separate applications it’s very clear that you can’t read the app properties of the main app from the helper since they are two different projects.

[/quote]

That brings to mind XojoScript…

In any case someone who thinks they can access the main App’s properties from a helper is not likely to be very successful writing helpers no matter how it’s done. No matter how it’s done, you need to understand what you are writing.

But I hear you that this is not something likely to happen anytime soon, if ever… I agree Xojo has a LOT on it’s plate for the resources available.

  • Karen

We played around with a preemptive thread version of XojoScript at one time and while it has uses again it is quite sandboxed so there are limits. With some creative thinking you can do some interesting things. Joe R wrote a Mandelbrot routine in it to demonstrate the speed you could get from it- but to pass an image you basically passed a few large arrays of RGB values - cant pass pictures :stuck_out_tongue:

It has VERY well defined points at which you can get data into and out of it and certainly most of the same kinds of limitations about passing objects back & forth that a “process” might have.

Quite honestly THAT could be made preemptive (we did it once already and shelved the idea). It’d need work to really be release ready but we have seen it work. But it’s certainly not what most folks think of when they think “multicore”. Most are looking for “magic” of some kind to suddenly make their loading of a zillion rows into a listbox fast. Thats not going to happen in any tool. And most of that has to do with the UI toolkits.

Brads not wrong about the algorithm being one of the big determiners.
If the algorithm doesn’t lend itself to being run concurrently then 1 core or 20 cores makes no difference.
Certain classes of tasks do because they can be nicely partitioned & run in parallel.
Searching & sorting can be good tasks as you can often partition the search in natural ways that can be recombined later (most big iron databases take advantage of this) Things like image manipulation can since you can often (but not always) slice the image and hand a chunk off to each process to deal with & recombine them later.

[quote=22880:@Norman Palardy]Saying this hiding behind a fake name deserves no further reply.
You won’t get any more from me.
[/quote]

Very unprofessional way to treat a customer of almost 10 years, Norman.

Classy.

I have written a set of classes that do something similar to what’s being asked.

  • There is an App which has two modes: Master or Helper
  • The app launches a 2nd (3rd, 4th…) copy of itself in the background as a faceless helper app
  • There is a cMessage class which allows an app to send a command to the helper app, and to get a response back
  • There is a cHelperApp class which manages launching of the helper app instances and round-robin scheduling of tasks to helper apps (if there are more than one)
  • Communication between the apps is via IPCSockets. Commands are sent back & forth as XML text objects with binary blobs.
  • It works on Mac & Windows

Unfortunately, it’s not code I can release to the public. But it does work and it is a useful technique. It was not easy to write & debug, however.

[quote=22944:@Michael Diehr]I have written a set of classes that do something similar to what’s being asked.

  • There is an App which has two modes: Master or Helper
  • The app launches a 2nd (3rd, 4th…) copy of itself in the background as a faceless helper app
  • There is a cMessage class which allows an app to send a command to the helper app, and to get a response back
  • There is a cHelperApp class which manages launching of the helper app instances and round-robin scheduling of tasks to helper apps (if there are more than one)
  • Communication between the apps is via IPCSockets. Commands are sent back & forth as XML text objects with binary blobs.
  • It works on Mac & Windows
    [/quote]

THis might be the harder way to do it since its the same app running in one of two modes.
I know why your application is the way it is but it might not be that common a need - esp since now console apps do have access to graphics routines etc which they didn’t at one time.

[quote=23003:@Norman Palardy]THis might be the harder way to do it since its the same app running in one of two modes.
I know why your application is the way it is but it might not be that common a need - esp since now console apps do have access to graphics routines etc which they didn’t at one time.[/quote]

Agreed - in my case there was a need to keep the delivered file sizes as small as possible and simplify installation - using one EXE or App, launched in two different modes, was a nice solution. But in general, it’s probably better for helper tools to be small & modular.