Share ram across several instances

Question

When running the same export several times, it can indeed open several times, but each instance runs a full copy of the engine.

How to have a single base engine that serves as core to every instance run.

I know the effect can be achieved using a single home node and having the several instances atached in the tree, and if we use godot4 to create several floating viewports, the effect happens.

But, its doable in system level, or the only way is to orchestrate the several instances using a dedicated meta-project that just handle the sub-projects?

In sum, how is the most realistic aprouch to run several independent instances of godot without memory replication of the base engine.
And across several diferent users(linux), and i know that this bit is the impossible request, but??

Thanks for insights

Holp

Answer 1

Debug > Run Multiple Instances

Juristic

Answer 2

I don't understand that. 😕

Froissart

Answer 3

That indeed created several copies of the debuged lanched instance from the editor.
But each had a self copy.

What i am striving for is having just the scene logic instanced in each of the runners. And all they sharing a single runtime.

Holp

Answer 4

I don't think that this is possible in any way other than using godot4's Windows. Different processes can't easily share RAM, so while it might be technically possible, I assume it would require significant changes to the core codebase.
Depending on your particular use case, it may be partially possible by using client-server architecture. For example, if what's taking a large amount of RAM is some form of simulation and the renderer only needs part of that simulation, you could have the simulation run on the single server and the clients would ask for results of the simulation (e.g., positions). But it opens a whole new can of worms and might not be relevant to your situation.

Fraternity

Answer 5

What i am striving for is having just the scene logic instanced in each of the runners. And all they sharing a single runtime.

What's your actual goal with this?

Juristic

Answer 6

In the particular current case, i am using godot as the env to several potencial implementations on a linux server.

The linux server has very low ram, and having each implementation run a quite simple logic on a centralized meta orquestrator project is setback by the need of having user isolation.

So, to have isolation i need memory duplication in each user for the instance of the godot runtime
OR
to have eficient paralelization i would need to sacrifce the multi-user isolation and have the centralized orchestrator, having in mind the potencial for escalation of a sub-service to acess the full tree of godot, and a potencial full runtime crash or halt of a sub-service that would inevitably crash all other sub-services because it would render the orchestrator runtime idle.

In sum, i just need to have several unrrelated scenes running with isolation and memory eficient alocation of runtime.

Its a pythonesque aprouch to godot. I am quite sure that each instance of a .py script DOES NOT alocate the full python runtime on memory.(It does not, right?)

But that may be a too edge case. But thats the full base scope. Several scripts with eficient and secure memory alocation.

Holp

Answer 7

Why just not use a single project then?

Juristic

Answer 8

• Tree scalation and exposure of states of all sub-services to a actor that compromises one of the services.
• Sub-service halt could potencialy stop all other because it can render the whole project idle.
• Same file system would be exposed to all projects, hence the need for multi-user support, or even chroot for each instance.

It may be that my security concerns are a early optimization case.
And the sub-service halt coud be prevented if the service scripts are implemented using threads.

So, idk. Is soft-isolation inside godot child-nodes strong? I know executing arbitrary code "is never safe", but maybe there is no running from virtualization in the end of spectrum, if isolation for safety is the way, and then, memory would become the problem again.

So... That gives me a ideia.

Maybe using Docker we can have a godot docker instance that coud be replicated and passed with diferent scripts, and the replications of the docker instance in the memory could be achieved in the way i am striving.

But now thats a docker problem, is anything in this liking possible there?
Aways balacing.... Anyway.

Holp

Answer 9

Why can't you just describe in simple terms what are you trying to make? Better chance that way to get useful suggestions on how to approach it. Using excessive ambiguous and abstract tech jargon while asking "how to" questions just muddies the water.

Juristic

Answer 10

Already stated.

I want to run paralel isolated scripts without memory inefficiencies.

And i put foward a solution not isolated that is using a single project to manage all scripts.

But i am concerned with the optimal balance between isolation and perfomance.

Because on the other way end of scope i could have several fully virtualized instances of linux subsystems just alocated too run a single godot project.(absurd)

What i am looking for here is, insights on where is the (sugested) balance?

Holp

Answer 11

This is not what, it's how. My question was what are you making. What are those parallel scripts for? What is the goal/purpose of the system you're building?

In other words, you're being too abstract. Bring it down a notch and tell us what this project is.

You went several steps ahead and started with assumed solution, instead of stating the actual task that needs to be implemented.

Juristic

Answer 12

I suspect(without really knowing what you are actually building tho, so just a hunch) what you really want is to network your project. You should be able to RPC over localhost if you don't need any internet connectivity.

You went several steps ahead and started with assumed solution, instead of stating the actual task that needs to be implemented.

https://xyproblem.info/

Fascination

Answer 13

Yeah the question exudes strong xy problem vibes 🙂

Juristic

Answer 14

First off, sorry for the delay.

Ok, so what i want is what i am proposing, its the abstact system, in itself.

If you want to know a aplications, so that to scape from the xy problem, cool idea, indeed, it is that.

A SaaS for godot instances.

But, if i spin up a godot instance for every microservice, be it a single script, be if a full scene with assets, it does not matter, the problem i am describing still haunts.

I just need to populate the entirety of the ram of a machine, with the data referent to the projects, WITHOUT having to duplicate the runtime along it.

BUT

I need somehow some strong isolation to prevent cross crash of projects and security.

Holp

Answer 15

Are you sure the OS doesn’t do this already for you if you run multiple processes?

Hoodwink

Answer 16

What's the benefit of using Godot for that?

Juristic

Answer 17

As shown in the print in :

No, the OS does not handle in the way needed, the isolation can happen, but at a cost of full duplication of engine in memory, making scalling of resources not viable.

And, the benefit of that is the same benefit you can get from any other paradigm of programming. Its just that i see GDScript as a python alternative, and godot can interface with the OS and can be "easily" extended as well, so it is suited to call that it a fully competent platform.

But, maybe i need to look on a more general aprouch to solve the problem i am striving here.

How other runtime based programming ecosystems manage to scale in that way? As mentioned early, pretty sure a miriad of Python or NodeJS scripts running in parallel does not invoke a self full copy of the runtime, for each instance.

Well, need to investigate and verify that. Maybe it indeed does? Or the runtime is module based and it is indeed duplicated, but with a minimal memory footprint based on the imported/used functions?

And even in the containerization paradigm, with i bet is one of the candidates to the solution, when one has several instances of the same image, does all the images get fully duplicated, or there is some base content that can indeed be shared without comprimises, and have the desired memory footprint minimized?

Well, i think the point is clear. And if it is indeed possible to have that isolation AND memory preservation on other runtimes, then it has to be possible here, too.

Holp

Answer 18

Since the start, i am aways avoid talking about the soft obvious solution...

The Thread base node.

It can run a determined function, and that function can call others, and as i know, it will all still be ocouring in the scope of the thread.

But, how to run a full tscn scene, with all the nodes and assets, each and single function as a isolated thread?

Maybe that can be the easy solution, if the thread lock indeed does not propagate to the main thread one, a whatdog can be implemented and kil the halt, and the full server will still be alive, and the resourse hog mitigated.

But that is the easy soluton, and what i mean to achive is a simple dropdown your project and get it running, but maybe that is just a naive thinking, and the easy solution is the only pratical one here for now.

Ok, that can do for me, maybe for just running scripts.

Its a first version of a not fully featured, but it can scale and fully alocate the server, with are the principal question here.

But that TOTALY lacks isolation, and will only works on a personal case to avoid resource alocation conflits (network ports, etc), and idealy it is to be open to arbitrary code execution, of external users..

Well.

Holp

Answer 19

Its just that i see GDScript as a python alternative

Then just write your thing directly in some programming language. Why drag along all the unneeded (and massive) game engine's overhead, and then bang your head against walls looking for dubious workarounds to eliminate it?

Juristic