| 08-28-2007, 04:56 PM | #1 |
So, the 8191 limit is way too small, but it may also be too big sometimes, I still doubt having plenty of arrays is a big issue, but there is no reason to have so much arrays, is there? Some structs typically have very few required instances, for example data for an spell would hardly need more than 50 instances. This is fixable by adding a maxinstances keyword (or maybe a better sounding syntax, open for suggestions) Like JASS:struct sss maxinstances 100 integer a real b endstruct struct ttt maxinstances 8000 integer per real timeelapsed endstruct It is plausible for the compiler to generate code that makes both structs use the same memory space, since 8000+100 <= 8191... |
| 08-28-2007, 05:58 PM | #2 |
I kinda like the idea of not having to worry about how many instances a struct must support. That would be the 'reason' for having so many arrays. However, if this would produce notable benefits it's worth considering. But my question is: Do you intend it to be mandatory? Edit: second question: What happens if you create more instances than the given amount? Will the code automatically revert to the old system or will it error? p.s.: maxinstances sounds ok |
| 08-28-2007, 07:51 PM | #3 |
hmm sounds nice also will spare some global vars space too |
| 08-28-2007, 07:58 PM | #4 | ||
Quote:
Quote:
|
| 08-28-2007, 08:11 PM | #5 |
Well, I have some considerations. The algorithm that determines which structs to team together would have to be pretty "smart". It would need to consider which structs have the most compatible members and also which structs have compatible values for maxinstances. Then there's the problem of naming the members, since it could no longer be neither a nor per. Wc3 doesn't care what variables are named like but for debugging purposes, it's useful if the jass code that gets generated by the preprocessor bears some resemblance to the original vJass code, and since the syntax gets greatly transformed the variable names are important in deciphering on which line exactly does the syntax error occur. I don't abuse structs too much anyway so this does not concern me, but I can see how this would be potentialy useful to grim001... that is, if you can somehow prove with benchmarks that having too many arrays actualy affects performance in a way that justifies the extra overhead (however small) in the struct code. |
| 08-28-2007, 08:14 PM | #6 | |
well ok =) but ! maxinstances is too looong =\ suggestions: struct xxx or struct mx xxx =) it's MUCH better... Quote:
i thinks there is no great difference. cause any array slot i allocted dynamicaly. so if you will have 1000 slots i 1 array or 10 with 100 does not matter (well maybe a bit). but ok test it ^^ any way it will nothing change for me. !!! btw hmmm =\ i had ~1K (or more) inited global vars and it does not affects performance (maybe a extreme little bit ^^) so i could not mention this by setting a variable 1K times. the results were the same. but anyway test it. |
| 08-28-2007, 08:16 PM | #7 |
Space for arrays is only allocated up to the last instance you assigned to the nearest power of two[1]. So no space savings, but you do load the fixed size global hash table less.. but that will be offset by the rebasing. I encourage you to not bother unless you're doing it because the filling the bag problem is interesting to you. |
| 08-28-2007, 08:18 PM | #8 | ||
Quote:
Well if someone would ask me to describe this in one word I would definitely say - USELESS Besides in half the time it would take you to make this you could make a demo map with say 1000 global arrays (simply make c++ program to generate that repetitive JASS code for you, that is what I did)
Make it a library, add chat event -gtest for example that will start a couple of functions that access (both read and write) those arrays (again c++ generated code but with random array numbers and indexes) and distribute it to us. We put it in our maps, start game on bnet and type -gtest if that about global array number is true a bounch of people will desync that moment, if not hurray we know we don't need to worry. |
| 08-28-2007, 09:05 PM | #9 |
Sounds pointless to me, number of arrays declared doesn't mean anything. |
| 08-28-2007, 09:05 PM | #10 |
cohadar u create 4096 location every time O_o ofc this may desync... |
| 08-28-2007, 09:06 PM | #11 | ||
Quote:
Lolz , indexes that are never used don't waste memory. Anyways I made that test I was talking about. WARNING, very very long trigger.
|
| 08-28-2007, 09:37 PM | #12 |
hmmm i have tested this trigger... and after it my war3 needed 117 MB memory (in Task Manager) so not allot ^^ well 90K used slots it's FUCKING ALOT! =) well conclusion =) arrays are our best friends ^^. btw... just tested... !!! i was right (dunno why ^^) after and before cohadars test the needed time to operate with arrays IS THE SAME ! (and we have here 90K used slots O_o !!!) well here the test map... A_R_R_A_Y_S___F_O_R_E_V_E_R_!_!_! =) |
| 08-28-2007, 09:50 PM | #13 |
90K ??? - where did you get this number ? one array = 8192 = 8K There is 1000 arrays in gtest, that is 1000 * 8K = 8000K --- Anyways I am glad we cleared this thing now. Structs forever. EDIT: Btw times before and after the test are same because I sort of "cheated" on the test Look at this line: JASS:call FillGlobals((100-i)*80 ,GetRandomInt(-10000, 10000)) (100-i) // <-------------<< I fill arrays FROM BEHIND. If you put simply i instead 100-i test will lag the game to death. Reason: array does not use all 8192 memory at once, it uses memory only until the biggest index If you fill it from front it has to increase it size every time you increase index. But if you fill it from behind it allocates whole array at once and after that game does not lag. That is the reason I have initializers in my systems: JASS:static method init takes nothing returns nothing set Key$X$[8190] = 1 set Key$X$[8192] = 0 set Value$X$[8192] = 1 set Value$X$[8192] = 0 endmethod So I initialize arrays before I use them and there is no lag. :P So Vexorian I suggest that instead of maxinstances you add init static method to structs |
| 08-28-2007, 10:09 PM | #14 |
I think it is a bad decision because you don't need efficiency all the time. The only places you need it in fact are periodic functions. That you optimize any way you like. But on other places layers of abstraction can really help you by reducing the time you need to make stuff and also making your code easier to understand and find bugs. My general opinion is that people waste too much time optimizing stuff that don't need to be optimized at all. |
| 08-28-2007, 10:09 PM | #15 |
Actually you can't do anything more efficiently than vJass. Obviously you can misuse it, but if you need the functionality of a given feature, you can't hand compile it faster. The abstractions are practically non existent and don't 'leak'. It's just
I don't care how you write your map, just pointing out facts. |
