Interesting idea. Using your 4GB example, how is the main app loading the data into shared memory and then telling each worker what address space they should work on, different from telling each worker to which section of the file to read?
It seems like both provide the same benefit. I suppose the exception would be that IF the main app had already read the file into memory for some other reason, it wouldn’t have to reload it after the workers were done but that’s an edge case.
In this particular example, the log data is coming from a shell object.
But I mean in general, a immutable shared dictionary per say?
Or an immutable shared array?
That’s not an edge case unless you’re saying this whole problem is an edge case. If you want any sort of redundancy, you need to consider that the “best case scenario” is that you’ll only need to load segments of that 4GB file once, but if any of them fail for any reason, you need to be able to access the original data again and then you’ve got a performance hit.
What I was imagining is that either (a) the main app reads the 4GB file directly or (b) it passes to workers locations of segments of the file. Of course if the data is coming to the main app over a socket, then the main app already has the data in memory in which case there is of course and extra hit because the main app would (today) have to write the file to disk or pass that day in some way to the workers.
FWIW, if you only had 4 workers, you wouldn’t want to pass 1GB of data over the wire. It’d just take too long.
To make sure we don’t get caught up in looking at the trees, I’ll try to explain what I am thinking one more time, especially as this conversation has helped me narrow it down.
Some additional notes:
The fact that without 3rd party plugins or declares, it has to be done this way is one of the limitations that I’ve been trying to get some attention on since Workers inception.
That shiny new Mac Studio Ultra you ordered, won’t make a lick of difference to your application (compared to a M1 Mini or M1 MBA) without serious work. I get that most Xojo customers don’t care or understand, but for those that do, it’s quite depressing.
Workers (or helpers in general) is key to getting more performance outa apps as we’ve been seeing CPUs with 64 cores and such for a while now.
I am prepared to invest my time into aiding Xojo create a more usable solution, but I’m not going to do so if Xojo isn’t interested.
There is quite a lot that Xojo is way behind on, I’d like to see that changed, now that hopefully the renaming garbage is over and done with.
I fear that they do not consider many of those type of things a priority, as I think they believe only a (very?) small percentage of the their users (or potential users) care about or need them.
-Karen
Workers will only allow you to do this in certain situations. Xojo needs better concurrency support than workers to really take advantage of multiple cores.
It is my understanding that Xojo needs to massively overhaul their framework for this to happen.
As Workers are already here, I feel with a collective push and guidance, we could help Xojo make Workers, work better for us, so that they feel closer to how it is in other languages and make it easier for all to run their Xojo applications faster on newer hardware.
But since like every chip design is based off more cores, and xojo is utilizing only a single one some day xojo may be choked on cpu… heck even microprocessors like arduino’s and esp32’s can utilize multiple cores pretty easy.
Some day xojo has to get multi core threading.
I’m all for making workers better. I just wouldn’t get my hopes up about what some improvements would suddenly allow you to do as the overhead of IPC and copying memory back and forth would probably negate the concurrency benefits in a lot of cases.
I know better concurrency support in Xojo will never happen but that will be the only way to really take advantage of today’s CPUs.
Like you, I’ve written a custom plugin with Objective -C and was shocked with how easy it was and after tinkering, the performance gain it provided.
IPC is out of the question IMHO, my earlier experiments with IPC showed it to be a bottleneck.
Shared memory was much much faster, even with copying memory, and did enable performance gains. Was it as fast as the Obj-C code? The answer lies with the fact that I shipped the app with the custom plugin.
However of there was a relatively simple solution within Xojo, that could get me (say even an additional 80%) I may have just stuck with that.
But my point is not that Xojo needs to do it correctly, is that I feel they should try to do better than what they got.
I don’t disagree with anything you have said and if workers could be improved to make them more useful then great. However, even with improvements their use is still limited, can greatly complicate development and debugging of code due to separating tasks across separate processes and can’t be used on mobile.
For what it’s worth Sam, I’m totally with you on this.
I agonised over whether or not to treat myself to a Mac Studio (I already have an M1-based Mac) but the reality is it offers nothing to me as a Xojo developer (aside from slightly faster compiling). It saddens me that Apple is clearly betting the farm on multicore and that none of our Xojo apps can make much use of that.
Workers in principle offer so many advantages but they are just too slow in their present state. I’ll give a concrete example - I am writing / have written a code editor in Xojo that highlights Markdown. It would be great if I could have a Worker parse the Markdown whilst the main thread handled the editor canvas but this just isn’t feasible without shared memory access.
For the record, shared memory access is easy enough using MBS plugins and I do it now in both macOS and Windows, albeit with previously written helper apps which predate Workers.
One day I’ll rewrite my helper apps as Workers to keep up the mantra:
“If it ain’t broke, fix it til it is!” 
I think everybody is betting on multi core.
If the markdown processing takes a non trivial time you might find it is easier to just use temporary files to pass the data back and forth.
Using shared memory potentially involves several steps that can introduce a lot of latency / overhead. I don’t think it would be possible to have Xojo data types in shared memory which means you would have to convert between the Xojo data type and a binary format and also copy between main memory and shared memory.
Why don’t you try the shared memory functions in the MBS plugins to see if shared memory would actually help.
I would like to see Xojo take baby steps toward real native threads. World has gone micro threads, computers have more and more cores and specialized cores, Small cores, large cores, Neuro cores, etc etc. Putting any kind of bets on Workers is just madness.
With other languages you make micro task in 3 lines of code basically by spawning up task. (which inside of it basically contains thread).
So to go forwards I would like Xojo to work on it in baby steps to get actual threads that is really the only thing that will make use of new hardware at end of the day. (and the only thing that will let Xojo catch up in this field.).
So baby steps could involve for example.
Make the Linked list which keeps tracks of Object locks and String locks thread safe. This means object can be created, referenced and dereferenced. (same with string) → Soon as you have this then already Plugins can do a lot more native threads than they can now. (so win right away even if small). (No direct win yet here without plugins I guess).
Make String and string functions thread safe, and make Xojo NativeThread object. (the old threads can probably co-exist which again would help with letting the fix go in baby steps). → At this point Xojo users could do a little bit in native thread directly.
Keep on adding core things, Date, Dictionary etc.
And so on…
It does not call for all at once
With each step you could advertise more and more as thread safe, making real threads over time more and more useful.
I put in feature request:
68072 - Please put mutex Lock and Unlock around Xojo memory management Create / Lock / Unlock.
Please put mutex Lock Unlock around Xojo memory management Create / Lock / Unlock
Doing this would change a whole lot for Plugins, and it would change a whole lot for those dealing with Hardware in GPIO, and it would put down solid foundation for Xojo to become Thread safe.
I have attached example how to do it and a test. The Test is simulating the Xojo memory management, CreateObject, Lock object, Unlock Object. (same would need to be done to strings obviously).
(Creating simulation of Xojo memory manager took around 20 min and then 10 min to make it thread safe and create the test for it.)