|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On March 08 2015 21:00 sabas123 wrote:
My idea was to have some kind of sorter that will do the filter and then give that to the function/system/processor (how ever you want to call it).
My intention isn't performance, but from what I read it should be possible to have faster performance with this kind of architecture then the traditional class hierarchy
The point of entity component designs is something along the lines of avoiding having to define a class for each possible combination of traits an object could have (like renderable, collidable, controllable and so on). It's about using composition instead of inheritance. It's not about performance and it's very unlikely that it has any performance advantages over a inheritance based system in a language like C++ simply because C++ virtual method invocation is about as fast as it gets if you need variable behavior among a list of objects.
In other languages this might be entirely different, specifically if methods aren't defined per class, but instead per instance. In that case you'd only ever need the methods of your few system instances instead of your many entity instances.
|
On March 08 2015 21:24 spinesheath wrote:Show nested quote +On March 08 2015 21:00 sabas123 wrote:
My idea was to have some kind of sorter that will do the filter and then give that to the function/system/processor (how ever you want to call it).
My intention isn't performance, but from what I read it should be possible to have faster performance with this kind of architecture then the traditional class hierarchy The point of entity component designs is something along the lines of avoiding having to define a class for each possible combination of traits an object could have (like renderable, collidable, controllable and so on). It's about using composition instead of inheritance. It's not about performance and it's very unlikely that it has any performance advantages over a inheritance based system in a language like C++ simply because C++ virtual method invocation is about as fast as it gets if you need variable behavior among a list of objects. In other languages this might be entirely different, specifically if methods aren't defined per class, but instead per instance. In that case you'd only ever need the methods of your few system instances instead of your many entity instances.
I saw some speakers at cpp con from google and sony I think talk about how to stepped to data oriented designs (from my knowledge entity based systems == DoD) because it had better performance and more maintainable code.
|
On March 08 2015 21:32 sabas123 wrote:Show nested quote +On March 08 2015 21:24 spinesheath wrote:On March 08 2015 21:00 sabas123 wrote:
My idea was to have some kind of sorter that will do the filter and then give that to the function/system/processor (how ever you want to call it).
My intention isn't performance, but from what I read it should be possible to have faster performance with this kind of architecture then the traditional class hierarchy The point of entity component designs is something along the lines of avoiding having to define a class for each possible combination of traits an object could have (like renderable, collidable, controllable and so on). It's about using composition instead of inheritance. It's not about performance and it's very unlikely that it has any performance advantages over a inheritance based system in a language like C++ simply because C++ virtual method invocation is about as fast as it gets if you need variable behavior among a list of objects. In other languages this might be entirely different, specifically if methods aren't defined per class, but instead per instance. In that case you'd only ever need the methods of your few system instances instead of your many entity instances. I saw some speakers at cpp con from google and sony I think talk about how to stepped to data oriented designs (from my knowledge entity based systems == DoD) because it had better performance and more maintainable code.
Data oriented design seems to be about placing similar data in a contiguous part of memory so it can be mass-processed more efficiently.
If a normal class has fields a, b and c, each instance looks just about like this in memory: (x, a, b, c) where x is, for example, the v-table pointer. And then those instances are potentially sprinkled all across your memory. That's "bad" if you want to do an operation on all fields a of all instances.
DoD suggests that instead of having fields a, b and c per instance, you have for example 3 vectors for the class - not the instance, one for each field, and if you need to access the "field" of a given instance, you look it up by index, for example. The key point being that all fields "a" are placed in contiguous memory.
I worked with something like that for my bachelor's thesis, but I still had normal instances and only copied the data into vectors before using it. The idea there was to lay the data out in a way that allows better usage of SIMD instructions. However this was for a molecular dynamics simulation on a supercomputer. Hardly the kind of performance requirements you'll face everyday.
Now, what you are doing - a list of components for each entity instance, and each component is an instance with normal fields: That's not DoD. You might be able to use a data holder like described in DoD for each kind of component and it'll be DoD, but as of now you're not doing that, and I wouldn't recommend it. For example because you'll have to do a lot more than just change your data storage layout to achieve a performance gain. And you more than likely won't need it.
|
On March 08 2015 15:30 nunez wrote:
what is the point of this component / entity based
design? i get a consistent handle to something for
the price of having all my types inherit from some
useless baseclass? i can get a consitent handle for
something wihtout paying that price. i'm not sure
i understand it at all.
and if you are storing stuff via pointer, sure the owners,
of the pointer are stacked up nicely in your blob of
memory but you have no guarantee that the objects they
own are. so when you iterate over the collection, you
are still jumping all over the place in memory.
Indeed. Component-based entities are all about reducing code complexity. They make it easier to add a wide range of things (data and behaviour) to a game. They also make serialisation easier. That base class can (and arguably should) be completely hidden inside the entity.
Iteration over contiguous memory is certainly faster. But it's an optimisation, and so has other costs. You also need to be very careful to know exactly what your access patterns and usage are in order to know exactly what, and how to optimise. You can't optimise everything -> you need to know whether you need fast lookup, fast iteration, or fast (or any) sorting.
What I've outlined is flexible and extensible, and if you need to make a specific aspect or system faster it's easy to do so, without even touching any of the "client code" (gameplay code that actually uses the entities).
@spinesheath: Yeah, the type casting isn't ideal. But the alternative would probably be getting components from the systems directly (since they'd know the type). And then you'd be looking through every component of a particular type for the right entity id, instead of looking through perhaps 3 or 4 components of different types and doing one type cast. I haven't measured which is faster (and it would depend entirely on one's usage patterns and the systems involved).
|
@spinesheath:
Can't it just mean that you are thinking about data structures beginning with what's your input data and ending with what's your output data, then let everything else in-between follow from there (also by describing the data you'll use there), while ignoring all OOP stuff like what procedures are tied to the objects and inheritance hierarchies and whatnot?
The data structures you would think about don't necessarily have to exist. You could think about data you'd like to have, like in that game perhaps stuff like "a list of all entities that need a change after the user clicked x", but then when you implement that, C++ probably has something neat you can use like a function producing streams of stuff that you can pipe into another function or whatever.
|
On March 09 2015 02:15 Ropid wrote:
@spinesheath:
Can't it just mean that you are thinking about data structures beginning with what's your input data and ending with what's your output data, then let everything else in-between follow from there (also by describing the data you'll use there), while ignoring all OOP stuff like what procedures are tied to the objects and inheritance hierarchies and whatnot?
The data structures you would think about don't necessarily have to exist. You could think about data you'd like to have, like in that game perhaps stuff like "a list of all entities that need a change after the user clicked x", but then when you implement that, C++ probably has something neat you can use like a function producing streams of stuff that you can pipe into another function or whatever.
If you're questioning the definition of DoD, certainly it might be something completly different, and as is common with buzzwordy design principles like that, there usually isn't a commonly agreed upon definition anyways.
However, if you want to do something with you data to increase performance, vectorizing your class' fields across all instances is the probably the best you can do. Especially if you can apply algorithms that utilize SIMD instructions.
|
On March 09 2015 02:42 spinesheath wrote:Show nested quote +On March 09 2015 02:15 Ropid wrote:
@spinesheath:
Can't it just mean that you are thinking about data structures beginning with what's your input data and ending with what's your output data, then let everything else in-between follow from there (also by describing the data you'll use there), while ignoring all OOP stuff like what procedures are tied to the objects and inheritance hierarchies and whatnot?
The data structures you would think about don't necessarily have to exist. You could think about data you'd like to have, like in that game perhaps stuff like "a list of all entities that need a change after the user clicked x", but then when you implement that, C++ probably has something neat you can use like a function producing streams of stuff that you can pipe into another function or whatever. If you're questioning the definition of DoD, certainly it might be something completly different, and as is common with buzzwordy design principles like that, there usually isn't a commonly agreed upon definition anyways. However, if you want to do something with you data to increase performance, vectorizing your class' fields across all instances is the probably the best you can do. Especially if you can apply algorithms that utilize SIMD instructions.
It seems super hard to add parallelization and concurrency to normal OO style programs. That data driven stuff feels like it might help with that.
Parallelization of work that needs to be applied to each object seems obvious enough. It will only be fine if the objects are completely separate and the work has no side-effects.
Concurrency seems more interesting. Perhaps if you think about processing a list of stuff as something that takes that list as an input stream of objects that then produces an output stream of new objects, you could try to use some sort of pipes to get use out of multiple threads?
|
On March 09 2015 00:47 spinesheath wrote:Show nested quote +On March 08 2015 21:32 sabas123 wrote:On March 08 2015 21:24 spinesheath wrote:On March 08 2015 21:00 sabas123 wrote:
My idea was to have some kind of sorter that will do the filter and then give that to the function/system/processor (how ever you want to call it).
My intention isn't performance, but from what I read it should be possible to have faster performance with this kind of architecture then the traditional class hierarchy The point of entity component designs is something along the lines of avoiding having to define a class for each possible combination of traits an object could have (like renderable, collidable, controllable and so on). It's about using composition instead of inheritance. It's not about performance and it's very unlikely that it has any performance advantages over a inheritance based system in a language like C++ simply because C++ virtual method invocation is about as fast as it gets if you need variable behavior among a list of objects. In other languages this might be entirely different, specifically if methods aren't defined per class, but instead per instance. In that case you'd only ever need the methods of your few system instances instead of your many entity instances. I saw some speakers at cpp con from google and sony I think talk about how to stepped to data oriented designs (from my knowledge entity based systems == DoD) because it had better performance and more maintainable code. Data oriented design seems to be about placing similar data in a contiguous part of memory so it can be mass-processed more efficiently. If a normal class has fields a, b and c, each instance looks just about like this in memory: (x, a, b, c) where x is, for example, the v-table pointer. And then those instances are potentially sprinkled all across your memory. That's "bad" if you want to do an operation on all fields a of all instances. DoD suggests that instead of having fields a, b and c per instance, you have for example 3 vectors for the class - not the instance, one for each field, and if you need to access the "field" of a given instance, you look it up by index, for example. The key point being that all fields "a" are placed in contiguous memory. I worked with something like that for my bachelor's thesis, but I still had normal instances and only copied the data into vectors before using it. The idea there was to lay the data out in a way that allows better usage of SIMD instructions. However this was for a molecular dynamics simulation on a supercomputer. Hardly the kind of performance requirements you'll face everyday. Now, what you are doing - a list of components for each entity instance, and each component is an instance with normal fields: That's not DoD. You might be able to use a data holder like described in DoD for each kind of component and it'll be DoD, but as of now you're not doing that, and I wouldn't recommend it. For example because you'll have to do a lot more than just change your data storage layout to achieve a performance gain. And you more than likely won't need it.
Vectorizing by lists of instance sounds like what a typical columnar data store tries to do (I've never worked with it personally but I think we some Teradata to store data for offline processing about stuff like customer retention models, etc.). Same reasons - faster to process column A when its (aaaaa,bbbbb,ccccc) then ((a,b,c),(a,b,c)...), so it's useful for some types of workloads (offline, batch processing) vs OLTP worloads I'd assume.
Sorry for all my twattery earlier guys. Anyway, today's daily dumb java question.
Checking some Java options and it mentions for -Xmx (max heap)
>> This value must be a multiple of 1024 and greater than 2 MB
But setting -Xmx1024k (minimum size for Xms) works fine for me.
+ Show Spoiler +
$ java -Xmx1024k -Xms1024k -server -XX:+PrintCommandLineFlags 2>/dev/null
-XX:InitialHeapSize=[b]1048576[/b] -XX:MaxHeapSize=[b]1048576[/b] -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
Also - anyone see difference between -client and -server options? I'm just checking them out on my Windows laptop so maybe it's different on different JDK but I see them as setting memory options to same
+ Show Spoiler +
$ java -client -XX:+PrintCommandLineFlags 2>/dev/null
-XX:InitialHeapSize=266849216 -XX:MaxHeapSize=4269587456 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
[Mon Mar 09 04:28:55 zebra@ZEBRA:~/personal ]
$ java -server -XX:+PrintCommandLineFlags 2>/dev/null
-XX:InitialHeapSize=266849216 -XX:MaxHeapSize=4269587456 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
edit: tried to post question on SO "Java Minimum Xmx option" and it kept rejecting my question as not having a good enough title so I gave up 
|
On March 09 2015 20:30 teamamerica wrote:edit: tried to post question on SO "Java Minimum Xmx option" and it kept rejecting my question as not having a good enough title so I gave up
Been reading about that kind of thing happening a lot lately from a few different people on forums. People will try and post perfectly valid questions that haven't been answered before and will get shut down because of some tiny nitpick. There was an interesting blog from a person who was a longtime, top of the pack SO contributor who said that it's getting to the point where new users are being chased away because some of the powers that be are becoming insanely pedantic about everything and are blocking valid questions simply because they don't like how they are worded or the topic. I've been meaning to start contributing there, but every time I go to, it just feels like a waste of time. I've also noticed the signal to noise ratio there is getting really bad when it comes to responses.
|
Currently im writing alot of structs and giving them an unique id to identify them later.
constantly looking up the latest id I putted in/looking up the id of the struct is a bit of an pain. any way I can do this automatically with something like an enum?
|
On March 10 2015 01:01 sabas123 wrote:
Currently im writing alot of structs and giving them an unique id to identify them later.
constantly looking up the latest id I putted in/looking up the id of the struct is a bit of an pain. any way I can do this automatically with something like an enum?
You could use a map/hashmap to pair an id with the struct itself, would this suit your needs?
|
On March 10 2015 01:01 sabas123 wrote:
Currently im writing alot of structs and giving them an unique id to identify them later.
constantly looking up the latest id I putted in/looking up the id of the struct is a bit of an pain. any way I can do this automatically with something like an enum?
I would use a combination of stringification macros, and post-compilation symbol tables. It's not a silver bullet, but now you only have to remember the index, not the entire ID. I have my build script setup to open up the symbol table after each compilation so I can quickly search for symbol names rather than grepping my code. Of course, a debugger is a better alternative.
Examples always help:
+ Show Spoiler +
#define struct_name(s) struct foobar_#s
struct_name(1) {
...
}
struct_name(2) {
...
}
struct_name(1).addfunct = adder;
struct_name(2).data = 11;
|
On March 10 2015 02:32 ThatGuy wrote:Show nested quote +On March 10 2015 01:01 sabas123 wrote:
Currently im writing alot of structs and giving them an unique id to identify them later.
constantly looking up the latest id I putted in/looking up the id of the struct is a bit of an pain. any way I can do this automatically with something like an enum? You could use a map/hashmap to pair an id with the struct itself, would this suit your needs?
I geuss I could try that.
|
On March 10 2015 01:01 sabas123 wrote:
Currently im writing alot of structs and giving them an unique id to identify them later.
constantly looking up the latest id I putted in/looking up the id of the struct is a bit of an pain. any way I can do this automatically with something like an enum?
The OOP way is using "virtual" functions. Behind the scenes, those are basically a pointer to a function getting added to the data structure. When you then have a base class and derive a bunch of specialized classes from it, and you then have a collection of elements of that base class, you can call that virtual function on any element of your collection, and what will run is the function from the specialized class without any type casting needed.
No idea if that's better or worse than doing things manually like what you're doing right now with your IDs.
|
On March 09 2015 20:30 teamamerica wrote:Show nested quote +On March 09 2015 00:47 spinesheath wrote:On March 08 2015 21:32 sabas123 wrote:On March 08 2015 21:24 spinesheath wrote:On March 08 2015 21:00 sabas123 wrote:
My idea was to have some kind of sorter that will do the filter and then give that to the function/system/processor (how ever you want to call it).
My intention isn't performance, but from what I read it should be possible to have faster performance with this kind of architecture then the traditional class hierarchy The point of entity component designs is something along the lines of avoiding having to define a class for each possible combination of traits an object could have (like renderable, collidable, controllable and so on). It's about using composition instead of inheritance. It's not about performance and it's very unlikely that it has any performance advantages over a inheritance based system in a language like C++ simply because C++ virtual method invocation is about as fast as it gets if you need variable behavior among a list of objects. In other languages this might be entirely different, specifically if methods aren't defined per class, but instead per instance. In that case you'd only ever need the methods of your few system instances instead of your many entity instances. I saw some speakers at cpp con from google and sony I think talk about how to stepped to data oriented designs (from my knowledge entity based systems == DoD) because it had better performance and more maintainable code. Data oriented design seems to be about placing similar data in a contiguous part of memory so it can be mass-processed more efficiently. If a normal class has fields a, b and c, each instance looks just about like this in memory: (x, a, b, c) where x is, for example, the v-table pointer. And then those instances are potentially sprinkled all across your memory. That's "bad" if you want to do an operation on all fields a of all instances. DoD suggests that instead of having fields a, b and c per instance, you have for example 3 vectors for the class - not the instance, one for each field, and if you need to access the "field" of a given instance, you look it up by index, for example. The key point being that all fields "a" are placed in contiguous memory. I worked with something like that for my bachelor's thesis, but I still had normal instances and only copied the data into vectors before using it. The idea there was to lay the data out in a way that allows better usage of SIMD instructions. However this was for a molecular dynamics simulation on a supercomputer. Hardly the kind of performance requirements you'll face everyday. Now, what you are doing - a list of components for each entity instance, and each component is an instance with normal fields: That's not DoD. You might be able to use a data holder like described in DoD for each kind of component and it'll be DoD, but as of now you're not doing that, and I wouldn't recommend it. For example because you'll have to do a lot more than just change your data storage layout to achieve a performance gain. And you more than likely won't need it. Vectorizing by lists of instance sounds like what a typical columnar data store tries to do (I've never worked with it personally but I think we some Teradata to store data for offline processing about stuff like customer retention models, etc.). Same reasons - faster to process column A when its (aaaaa,bbbbb,ccccc) then ((a,b,c),(a,b,c)...), so it's useful for some types of workloads (offline, batch processing) vs OLTP worloads I'd assume. Sorry for all my twattery earlier guys. Anyway, today's daily dumb java question. Checking some Java options and it mentions for -Xmx (max heap) >> This value must be a multiple of 1024 and greater than 2 MB But setting -Xmx1024k (minimum size for Xms) works fine for me. + Show Spoiler +
$ java -Xmx1024k -Xms1024k -server -XX:+PrintCommandLineFlags 2>/dev/null
-XX:InitialHeapSize=[b]1048576[/b] -XX:MaxHeapSize=[b]1048576[/b] -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
Also - anyone see difference between -client and -server options? I'm just checking them out on my Windows laptop so maybe it's different on different JDK but I see them as setting memory options to same + Show Spoiler +
$ java -client -XX:+PrintCommandLineFlags 2>/dev/null
-XX:InitialHeapSize=266849216 -XX:MaxHeapSize=4269587456 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
[Mon Mar 09 04:28:55 zebra@ZEBRA:~/personal ]
$ java -server -XX:+PrintCommandLineFlags 2>/dev/null
-XX:InitialHeapSize=266849216 -XX:MaxHeapSize=4269587456 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
edit: tried to post question on SO "Java Minimum Xmx option" and it kept rejecting my question as not having a good enough title so I gave up
What version of java are you running? All of the command line options are specific to the jvm you are running on.
From the java docs..
-server
The 64-bit version of the JDK supports only the Server VM, so in that case the option is implicit.
|
On March 10 2015 03:01 Ropid wrote:Show nested quote +On March 10 2015 01:01 sabas123 wrote:
Currently im writing alot of structs and giving them an unique id to identify them later.
constantly looking up the latest id I putted in/looking up the id of the struct is a bit of an pain. any way I can do this automatically with something like an enum? The OOP way is using "virtual" functions. Behind the scenes, those are basically a pointer to a function getting added to the data structure. When you then have a base class and derive a bunch of specialized classes from it, and you then have a collection of elements of that base class, you can call that virtual function on any element of your collection, and what will run is the function from the specialized class without any type casting needed. No idea if that's better or worse than doing things manually like what you're doing right now with your IDs.
My structs only will have variables not fuction. so I can't use them:/
|
trying to program Bluetooth code for the MSP430 is really difficult! Dah! It seriously is a tool made for employee comfort & not employer production.
|
|
|
Ok, so I have a programming problem I'm trying to solve. Any help would be appreciated.
I'm scheduling users to daily jobs for a given month. I have a specific set of users and a specific set of jobs. However, one day might not have the same set of jobs as another. There are various hard rules, such as not allowing one user to be scheduled more than twice in a day - hard rules can't be broken. There are various soft rules, such as scheduling the same user to the same job two days in a row - soft rules can be broken. I want to write a program that will give me the best combination for a given month - one combination is better than another if it breaks less soft rules (no combination is good if it breaks any hard rule). I also want to be able to add or remove rules easily, so there's no dependency on the rules themselves, only that they are either hard or soft.
The difficulty I'm having is that you can't really put a score on a user to a job unless you've accounted for all other jobs due to the nature of the rules. For example, I can't say that adding John to job 2 on day3 is good or bad unless I know if he was already added on that same day. So it seems to me then that dynamic programming is out because you can't break the problem down into smaller components to solve. Also, I don't think brute forcing will work if you have a large amount of job types, users, and jobs per day. Too many variations.
Any help you can offer would be appreciated!
|
Do you need to find the best solution (global optima) or a "good enough" solution (local optima)?
What is the rough user/job size? Hundreds, thousands, millions, unlimited?
Adding / removing rules depends on your rule complexity. Changing a rule can be easy (not working 3 days in a row), but adding a completely new rule might be complicated (user X doesn't like to do job Y, but he can do it if necessary).
If you don't need the global optima I would look into genetic algorithms. The fitness function sounds easy enough to implement with your set of rules and hard-rule breaking offspring can die off immediately.
|
|
|
|
|
|
EPT
