Entt: possibility with eastl container compatibility ?

[Milerius]

it's possible to let the user choose between stl to use ? like https://github.com/electronicarts/EASTL
I didn't benchmark yet but i think for the registry etc he can be a great choice for the users with cmake may be like -DENTT_USE_EASTL_LIBRARY, it's just an idea, may be you want to avoid dependencies as your maximum and i understand this point of view !

[skypjack]

Does EASTL offer all the stuff EnTT uses from the standard template library? I mean: vector, shared_ptr, unique_ptr, forward, move, and so on... pretty much all what you can find searching for std:: (I'm not a fan of using namespace directives fortunately). I've never used EASTL before, so I'm not sure about it, but this is the first point if we want to try it.

[danielytics]

So, I was looking at EASTL myself a few days ago (and was actually wondering about EnTT compatibility too, so I peeked at the code). From what I can tell, EASTL is mostly a drop-in replacement for common stuff. It adds some additional methods here and there and it adds a ton of new containers, it also has its own stuff for memory management/pooling, but the core STL API's remain intact as far as I can see.

So, theoretically, it would be a matter of typedef'ing the containers/smart pointers and then using preprocessor directives to select between std:: and eastl:: types.

I'm pretty sure that everything up to C++17 is supported, or at least, most stuff. I would guess everything EnTT needs is, anyway, but I guess we won't know until somebody tries.

I'd be happy to give a proof of concept a shot once I get around to trying out EASTL for my own project, but it may take me a few weeks depending on how busy I am with other stuff.

[danielytics]

Ok, I just took a quick look at EASTL: it does have support for vector (and pretty much all other containers and then some, including intrusive versions of the containers), shared_ptr, unique_ptr, forward and move (and therefore presumably everything else EnTT needs). It does define its own eastl::forward and eastl::move though, which it does because EASTL is designed to work in pre-C++11 codebases too (in which case those functions are no-ops), but the C++11 and beyond implementations look to be the same as the std ones. I'm unsure if everything in std:: should be typedef'd and replaced with eastl:: or not though... (Need to check how compatible they are too, I wonder if #define std eastl would work?)

[Milerius]

maybe i will give a try this week, and will try common things if i can get entt to compile, but if it's work the interesting part should be the benchmarking with entt/eastl vs entt/stl

[Milerius]

I am currently doing a c++ engine based on the sfml, with the objective of performance, I planned to use eastl, entt, sfml, speedlog, sol2, box2d, I really think that eastl is something to think more and more in video games, because they have worked a lot on the performance of their containers, and combined with the intelligence of the project that is ENTT I'm sure we would arrive at something incredible.

also in your todo file:
"create dedicated flat map based on types implementation (sort of "type map") for types to use within the registry and so on..."

seems to have an equivalent in eastl no ?
https://github.com/electronicarts/EASTL/blob/master/include/EASTL/vector_map.h
should be an approach if you want to do both compatibility

[skypjack]

@danielytics

I wonder if #define std eastl would work?

My two cents: it doesn't look like a good idea to abruptly replace std with eastl. :-)

@Milerius @danielytics

maybe i will give a try this week, and will try common things if i can get entt to compile, but if it's work the interesting part should be the benchmarking with entt/eastl vs entt/stl

I'd be happy to give a proof of concept a shot once I get around to trying out EASTL for my own project, but it may take me a few weeks depending on how busy I am with other stuff.

It would be great if you can try to integrate EASTL and then you came up with some benchmarks, before to start working on it my side. Help on this is appreciated, my free time isn't that much unfortunately.
Keep in mind also that I'm planning to use the pmr:: namespace from the standard template library (C++17) to introduce custom allocators within EnTT, so everything must be designed carefully not to make the maintenance of the project a hell in future.

seems to have an equivalent in eastl no ?

I don't think they are the same thing. What I want to put in a dedicated file is a container (namely a vector-like class) where keys are types instead of indexes. That is pretty much what I'm using within the registry to keep track of the pools of components.
Maybe the comment in the TODO file ins't that clear but, well... it's me writing down some notes, I didn't think users would have read it so carefully after all!! :-)

[Milerius]

im working on something like this, i think it's a better approach than macros:

#ifdef ENTT_USE_EASTL
#include <EASTL/vector.h>
#include <EASTL/tuple.h>
namespace entt
{
    namespace stl
    {
        template<typename T>
        using vector = eastl::vector<T>;

        template<typename ...T>
        using tuple = eastl::tuple<T...>;

    }
}
#else
#include <vector>
#include <tuple>
namespace entt
{
    namespace stl
    {
        template<typename T>
        using vector = std::vector<T>;

        template<typename ...T>
        using tuple = std::tuple<T...>;
    }
}
#endif

also i found this: https://rawgit.com/electronicarts/EASTL/master/doc/EASTL%20Modules.html
very interesting

[danielytics]

My two cents: it doesn't look like a good idea to abruptly replace std with eastl. :-)

I meant as a proof of concept, to test compatibility.

[skypjack]

@Milerius The sole drawback I see with this approach is that it's pretty annoying to add a _third alternative_ in case it happens sooner or later.

[Kerndog73]

You might be able to use namespace aliases (I completely forgot these things existed until now!).

#ifdef ENTT_USE_EASTL
#include <EASTL/vector.h>
#include <EASTL/tuple.h>
namespace entt
{
    namespace stl = eastl;
}
#else
#include <vector>
#include <tuple>
namespace entt
{
    namespace stl = std;
}
#endif

That way you avoid declaring everything individually. So if you wanted to add a third stl, you would just have to #include all of the required headers.

[Milerius]

yeah you should go on something like that ! great idea i'm busy until the end of this week, will give a try next week

[skypjack]

@Kerndog73 @Milerius
It would be great if one of you can benchmark it and see if it's worth it in terms of performance.
My only concern is that std:: and stl are really close to each other and it's easy to make a mistake while developing EnTT. Probably we should find a _better_ name for the namespace, even though I've not a good one to propose.
What about?

[Milerius]

@skypjack you can use a longer word like standard_library:: if you care about meaning, i mean when you ask about benchmarks we can but we have lot of benchmarks stl vs eastl free over the web right now. But in case of EnTT, which kind of benchmarks you want to try ? Iteration ? Entity Creation, etc ?

[skypjack]

Well, out of curiosity, what's in the benchmark dir would be enough for me actually. :-)

[Milerius]

https://rawgit.com/electronicarts/EASTL/master/doc/EASTL%20Benchmarks.html

and a more recent made by me:

https://gist.github.com/Milerius/cb094497fa900352645c80bb24bca587

[skypjack]

Any news on this?

If someone is willing to try it, I can leave the issue open.
Otherwise, I prefer to put a note in the TODO list and close it.

Let me know. Thank you.

[Milerius]

as i say, i did the last benchmark, but currently i'm to busy to try an implementation for EnTT, may be you can put it in note, and we will try it soon

[danielytics]

I’d say leave it open for a little while longer. I’ll be happy to give it a try, but it may be a few more days before I have time to take a look. Maybe check again in a week and if there’s no progress made, then you can add to the TODO list and close this?

[skypjack]

@danielytics We have a deal. :+1:

[skypjack]

I see a problem with replacing everything and just use another namespace.
My idea was to rely on pmr:: namespace to make EnTT allocator-aware. However, I just saw that EASTL doesn't offer the same functionalities.
The risk is to end with two branches and therefore two implementations of EnTT to maintain. :-(

[Milerius]

as i said in an another discussion, you should see https://www.youtube.com/watch?v=FLbXjNrAjbc

pmr:: is not perfect, may be we should have a discussion on the usefullness of PMR for EnTT

[skypjack]

pmr:: is not perfect, may be we should have a discussion on the usefullness of PMR for EnTT

Sure, feel free to contact me by mail (you can find it in the profile) and let's discuss about EnTT.
It's always a pleasure for me to talk about this project!! I really love it.

[skypjack]

@Milerius @danielytics Any news on this? I suspect it conflicts also with #93, even though I'm not that sure and I cannot check it right now (I'm from mobile).

[danielytics]

Unfortunately I still haven’t had the time. If you want to go ahead and close this now, go ahead and I or @Milerius can reopen it when either of us finally get to trying this out.

[skypjack]

@danielytics Unfortunately it's not only a matter of going ahead or not.
Supporting EASTL is somehow incompatible with #94 (there is nothing like std::execution::par in EASTL as far as I can see) and with pmr:: (of course, I'm not sure I'll use pmr:: but it's a fact). In general, we cannot develop EnTT in a way that just works out of the box both with the standard library and with EASTL. It requires a bunch of ifdef all around and some functionalities will be available only with the standard library, some others only with EASTL, and so on.
I'm not that sure it's worth it and a POC would help clarifying it.
To be clear, it's tempting to create a library that offers multiple backends and I'd be glad to work on it full-time, but I'm doing all of this in the free time and developing two branches would slow down everything. It's already quite a hell to make EnTT available for the three major compilers, trust me!! :-)

[danielytics]

@skypjack Sure. Do what you gotta do! My own personal views are below, although they probably aren't too relevant to EnTT as a tool, which should probably stay generic and 3rd party library agnostic.

For my own personal use, C++17 is still too new sadly, so I'm not personally particularly interested in pmr for now.

I also like EASTL since its been designed specifically for use in games, but of course, for a general purpose library such as EnTT, it doesn't make sense to rally behind a third party lib over the language standard library, so I totally understand why you may want to stick with pmr.

As for parallelism, again, personally, I don't have much use for std::execution::par because:

• I don't have much (easy, at least) control over the parallelism (technically, I can create my own executors and then tell the loop to execute on that executor, but that again complicates the EnTT API)
• I either need to make sure to only modify each component from one place or I need to implement synchronisation
• I want a proper task/job system rather than just parallel each function anyway and would rather tightly integrate with that

Therefore, again, personally, I don't really care for or want any special support in EnTT itself and instead want it to let me work with other task-based tools (eg Intel's TBB) so that I can build my own custom task-based execution mechanisms where I can tightly control how things are executed (and how and when components get written to).

That's how I plan to use EnTT and not really a reason not to support standard library functionality. If others find it useful to be able to loop through entities in parallel and its not hard to implement (seems its not hard!) then EnTT should absolutely support that. I'm just stating why its not something I need.

Given that I'm already on board with EASTL's memory management (and don't yet know enough about pmr to use it), that I want to use a full blown job/task system over simple parallel loops and that EASTL promises to have more performant containers than STL, I'm still interested in a proof of concept for this, even if its a fork/branch that isn't ever merged back in.

[skypjack]

@danielytics Got your point. Thank you.

I want a proper task/job system rather than just parallel each function anyway and would rather tightly integrate with that

This sounds like something we could implement in EnTT too. If you ever find the time to talk about it, feel free to write me a mail... :-)

[skypjack]

@danielytics I'm waiting for your mail, don't forget it!! It looks like you had a good idea about something to include in EnTT.
Meanwhile, I'm closing this issue because currently nobody can work on it and there are several problems that I'm not sure we can overcome. I added a note to the TODO file about EASTL. I'll have a try with it in future, but I cannot guarantee it will be integrated in EnTT.
Feel free to reopen this issue if you find the time to test it and you come up with a good idea on how to integrate it.

Thank you all for the interesting discussion.

[danielytics]

@skypjack I want to experiment a little more and solidify what I want. Ideally, I'd like to implement a demo of how I want to use EnTT and then we can discuss if there's a better way or if there's something EnTT could add to make it play nicer, but I'd like to try it out properly first. I'll email you once done.