LÖVE

it need for project (not game)...
dinamic map 1000x1000 titles. (small version)
1000000 object (this object constantly moving) * 3 z layers = 3000000
pos + pos ---- faster, than: pos.x + x; pos.y + y
If i use {x,y} or anyfing else ////

And ---- LuaJIT's memory limited to 1-2 GB ...

i cud take C, but... render, OpenGl, save\load data, parsing JSON, ... tolong write code.
Unreal engine, Unity .... nocoments

I sincerely hope you're not under the impression that anything having a world size of 15 000 000 x 15 000 000 tiles, let's say, with 1 kilobytes of data per tile, really keep all tiles in memory.

They usually do both graphical culling, processing only the region that's visible, via camera systems/modules/libraries, and more importantly, that's exactly why regions/zones/whatever you want to call them, are used extensively in many games... and there are analogous things in other program types as well. (Like bouncing audio to hard disk so the cpu doesn't need to process it in realtime in composing programs)

But still, having 3 million objects on screen is kinda overkill... that said, you didn't exactly tell us what your project is so i might be judging you a tad too harshly.

I'm just saying, doing anything sane, you shouldn't come near the 2GB limit of luaJIT...

on the other hand, luaJIT is limited, Löve is i think not, if you're using threads, since each thread is a separate lua state... might be wrong though, but i think i'm right for once...
(Also, löve objects don't even count into that limit, only their references)

15 000 000 x 15 000 000 tiles - realy overkill)))
and i not render it, all data going to log in text mode, but i need GUI to control and see group state
using threads - good idea )
project and algoritm samiliar https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life.....

Okay, i get it, and yes, Conway's game of life, and similar cellular automata indeed need to have all cells/elements updated every "tick" (in general)

And this is why there is probably still ongoing research about how that one particular c.a. can be calculated with more speed using sophisticated tricks, as how hash-life does it.

it similiar Conway's Game of Life, but not it
Yep, i use graph and binary tree, but i need store links for fast search in graph
store 2 values in 1 - help it - 197 vs 33mb (78mb in C scruct, but C struct create and calculate slower...)
I dont need superspeed and super optimization (OpenCL, preHashing, multitreading), speed enough (memory not enough )

zorg wrote: ↑Sun May 07, 2017 6:53 am ..., as how hash-life does it.

see Drawbacks ...

Like many memoized codes, Hashlife can consume significantly more memory than other algorithms, especially on moderate-sized patterns with a lot of entropy, or which contain subpatterns poorly aligned to the bounds of the quadtree nodes (i.e. power-of-two sizes); the cache is a vulnerable component. It can also consume more time than other algorithms on these patterns. Golly, among other Life simulators, has options for toggling between Hashlife and conventional algorithms.