TheExDeus
|
|
Posted on: April 29, 2014, 03:16:02 pm |
|
|
Joined: Apr 2008
Posts: 1860
|
Found a GM topic here: http://gmc.yoyogames.com/index.php?showtopic=604444Some users basically tried to measure several different variable read/write performances. So I though I could compare to ENIGMA. Sadly I don't have YYC so I can't test it, and comparing to regular GM wouldn't really be fair. So this is YYC from the topic: So here is ENIGMA: It does seems we are faster at few and slower at others. Comparing the two isn't correct though, as the YYC result wasn't done on my PC. But I do believe some of the iterative methods we have now are indeed slower than YYC could have (as theirs could be coded better, as it is few years newer as well). Just for comparison here is what happens when the "var" is replaced by "int" (so when we declare the type): We can see that all of the ones which previously used "var" and were slow are now A LOT faster. Some went from 3000us to 0us (to it was not even measurable) while others went from 115000us to 7000us (16x speedup). Many others didn't change because I can't override things like built-in variables to use int. So I changed only the ones having specific "var" declaration. I also changed the string, so you can actually see which ones were changed. So look for the ones having "int" in the name. So while there are things we should improve engine wise, we still have the ability to define variables that give a massive speedup. And I encourage people to use them. This topic was created in the "series" of the other topics involving variables.
|
|
« Last Edit: April 29, 2014, 03:19:40 pm by TheExDeus »
|
Logged
|
|
|
|
Darkstar2
|
|
Reply #1 Posted on: April 29, 2014, 04:09:24 pm |
|
|
Joined: Jan 2014
Posts: 1238
|
Interesting, now in real world, does this matter ? People judge the games by the overall frame rate. Even under worst scenarios with tons of variables and such would probably not reduce game speed by something noticeable most people would perceive. Also the YYC would probably yield better result compared to non YYC, as this is CPU operations, and the YYC benefits CPU and not GPU intensive games. Also I would think that the memory speed can have an impact too, depending on people's configuration but again, we are talking very precise measurements that would not be noticeable in most cases, if at all. I don't have YYC to test this
|
|
|
Logged
|
|
|
|
|
|
|
|
|
|
|
FroggestSpirit
|
|
Reply #9 Posted on: May 02, 2014, 11:04:42 pm |
|
|
Joined: Mar 2013
Posts: 79
|
I'm working on switching my known variables over in Project Collidascope. This leaves me with a few questions... Can arrays be declared as specific types? if so, how? Can we make data structures like in C++? I think there should be highlighting for the variable types, or bold it like when you type var
|
|
|
Logged
|
This isn't easy to say, but…
|
|
|
TheExDeus
|
|
Reply #10 Posted on: May 03, 2014, 07:46:10 am |
|
|
Joined: Apr 2008
Posts: 1860
|
Can arrays be declared as specific types? if so, how? Can we make data structures like in C++? The answer for now I think is that you cannot. It's a parser bug as it tries to use GM arrays instead (which are actually functions). Like: some_array[10] = 0;; some_array[0] = 5; Actually turns into: some_array(10) = 0; some_array(0) = 5; While real C++ arrays need to be: local int some_array[11]; some_array[10] = 0; some_array[0] = 5; So compiler errors out. For now there is nothing you can do to go around this bug (as far as I know). The second problem with structs is the same. You cannot use them until the parser is done. Josh keeps "working on it", but hasn't given any real indication on when he plans to finish or what problems does he have now. I think there should be highlighting for the variable types, or bold it like when you type var This is an LGM issue. I think some of the keywords are now hard coded which they shouldn't be. I think keyword lists (both functions and otherwise) be external, so it would allow easy additions of these kinds of things.
|
|
|
Logged
|
|
|
|
Goombert
|
|
Reply #11 Posted on: May 03, 2014, 01:12:38 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
They are hard coded when ENIGMA is not plugged in, when ENIGMA is plugged in keywords for functions but not types are added by ENIGMA.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
Josh @ Dreamland
|
|
Reply #12 Posted on: May 17, 2014, 08:41:27 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
I'm glad we actually have a benchmarking tool. This can be fixed with a little reflection, and depending on the user's mood, a little memory. Throughout ENIGMA's past, I've hemmed and hawed about how to treat variables referenced in with blocks. The current behavior is to look them up in the same manner as ID-referenced variables. The other behavior was to scope them into everything, so they exist and are located in the same place in every object, and therefore are trivial to access.
A third behavior I have not attempted is using virtual tables to store the variable access methods. This would make arbitraryId.myvariable into getter(arbitraryId)->get_myvariable(). This moves the burden from a switch statement based on object index to a simple virtual call. We're probably already incurring a by-pointer function call, so this could only mean savings.
The simplest way to take care of the whole "var" fiasco is with some static analysis of the code. This cannot be done with the current compiler.
Note: the behavior you are seeing, ie, GM being faster at setting a single var index, is due to the fact that GM's variables are always a map. So nothing special is constructed when you need to assign to a var. It's not that assigning to a var is expensive—constructing one is. There might be a way to improve that by enforcing a single var implementation, and moving the contents of var4_lua.cpp into var4.cpp. This would remove the need to do the allocation tricks I've done, and expose all code to the optimizer. Another quick trick might be replacing std::map with a faster map type; you could try hash_map.
Please do a benchmark with variant instead of var.
|
|
« Last Edit: May 17, 2014, 08:49:00 am by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
TheExDeus
|
|
Reply #13 Posted on: May 17, 2014, 10:01:26 am |
|
|
Joined: Apr 2008
Posts: 1860
|
Here is result by replacing every "var" with "variant": I actually thought that it is the same thing. But variant is actually faster in almost every case. The benchmark should actually be written better, but I didn't want to modify it so we could compare to GM. We could make it so we can compare with different ENIGMA types though.
|
|
« Last Edit: May 17, 2014, 10:12:57 am by TheExDeus »
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #14 Posted on: May 17, 2014, 11:37:38 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Variant is scalar (unless you count the fact that string is an array itself). Var uses some memory magic to throw together a Lua table. Construction time is pretty horrifying, but it has a good use time. Those global assign times are horrifying. I'm not sure how to deal with those, but since they are literally worse than assigning instance variables, I do have one obvious solution. Don't get me wrong; the with assign times are abysmal, but those can stand for some obvious improvement.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|