Advertisement
Guest User

rantbant

a guest
Jun 21st, 2012
196
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 12.52 KB | None | 0 0
  1. <arand> Yeah, I was thinking I coulf set a bunch of globabl variables using a loop
  2. * Rygar has quit (Quit: Red Eclipse, www.redeclipse.net)
  3. <thedardanius> hey, Im a C++ dev, are there any red eclipse devs here?
  4. <thedardanius> I have a suggestion for you
  5. <Hirato> do [ local bob; bob = "not sally" ] <-- bob's stack is popepd afterwards and it's not udnefined
  6. <Hirato> do [bob = 2]; echo $bob will give you two
  7. <quin> oh, must have changed, i used to have issues with it
  8. <thedardanius> any redeclipse devs here?
  9. <arand> What I'm kind-of trying to do is http://paste.debian.net/175649/
  10. <Hirato> no devs, jsut cowboys, yeeeeeehaw!
  11. <thedardanius> dafuq
  12. <Hirato> quin: same as always, the local keyword is new though
  13. <thedardanius> what langauge are you talking about
  14. <thedardanius> C++?
  15. <thedardanius> C?
  16. <arand> thedardanius: Yes there are
  17. <pk1001100011> o.o
  18. <Hirato> let's say it's C+-
  19. <thedardanius> are you a dev?
  20. <Hirato> :|
  21. <thedardanius> hirato, u clearly have no understanding of C++
  22. <arand> thedardanius: We're talking about cubescript the cube2 engine scripting lang
  23. <thedardanius> oh
  24. <thedardanius> like that
  25. <quin> Hirato is being facetious
  26. <pk1001100011> hey, Im a C++ dev; what langauge are you talking about; C++? O.O
  27. <thedardanius> yeah
  28. <thedardanius> nornak qestiob
  29. <thedardanius> *question
  30. <Hirato> I'm surprised he could say that after the code samples
  31. <thedardanius> but I have a sggestion for the engine
  32. <thedardanius> if there are any devs online now...
  33. <quin> you'd probably want the cube engine forums then
  34. <quin> we're just a game
  35. <Hirato> let's hear him out anyway
  36. <thedardanius> anyway
  37. <thedardanius> ok
  38. <Hirato> might be something that's not.. appropriate for sauer
  39. <thedardanius> well I think some parts of the engine could be converted into more C-ish code
  40. <quin> i suppose
  41. <thedardanius> since using some C++ feautures slow down the performance
  42. <thedardanius> but its just for some small parts
  43. <thedardanius> I mean
  44. <thedardanius> C++ is powerful, but when using certain attributes it might be a small nuisance. THen I prefer C
  45. <quin> i'd caution you not to make generalisations without making specific examples
  46. <thedardanius> ok
  47. <FallenWarlock> thedardanius: http://cubeengine.com/ <-- Cube engine website
  48. <thedardanius> so like that the cube engine sometimes uses virtual functions
  49. <thedardanius> or templates
  50. <thedardanius> nothing wrong about that
  51. <thedardanius> but with virtual fuctions
  52. <quin> in the struct abstractions, yes
  53. <thedardanius> I would recommend not to use these
  54. <thedardanius> but its up to the des finally ;p
  55. <thedardanius> *devs
  56. <quin> i don't think he would have used it if he thought it was going to be a major problem
  57. <thedardanius> Im not sayin its a major problem
  58. <arand> So is it possible to do some (pseudocode) "for i in list set list[i]_var = i" and get word_var:s to be available globally?
  59. <Hirato> the only ones I know of are used with the stream structure, the functions that are overridden are pure abstract and optimised quite efficiently by the compiler
  60. <thedardanius> did you read what i said before
  61. <Hirato> I think...
  62. * Kastra117 (~kastra@2.30.190.202) has joined #redeclipse
  63. <thedardanius> its that tese C++ are powerful
  64. * Patrik (~Patrik@p4FE574E1.dip.t-dialin.net) has joined #redeclipse
  65. <thedardanius> but since optimal optimization is right to do now
  66. <thedardanius> we can go a step down to C
  67. <thedardanius> since the main code is finished
  68. * Patrik is now known as Guest55277
  69. <thedardanius> we can do some precise optimizations
  70. * Guest55277 has quit (Client Quit)
  71. <quin> it's never finished really, heh
  72. <thedardanius> well the main code is
  73. <quin> there is no stable API in cube
  74. <thedardanius> not finished
  75. <thedardanius> WTF
  76. <thedardanius> im not talking about the API
  77. <Hirato> you'd probably want to talk to eihrul about that stuff too, I doubt he'd approve though
  78. <thedardanius> cube doenst even have a API
  79. <thedardanius> its an engine
  80. <thedardanius> never mind
  81. * quin scratches his head
  82. <thedardanius> Hirato, no offence, but gtfo you dont even know exaclty what Im talking about
  83. <thedardanius> stop interupting me and the others
  84. <thedardanius> youre almost a nuisance
  85. * quin looks at Hirato
  86. <quin> go for it man
  87. <pk1001100011> 3
  88. <Hirato> I am well aware that the compiler inlines the template stuff, a more "C like" adaptation of them will not net us any speed boosts
  89. <pk1001100011> 2
  90. <pk1001100011> ;)
  91. <pk1001100011> Be… I was thinking about kick, not answer. :(
  92. <thedardanius> true for some parts
  93. <thedardanius> but it is true that inlining generated larger but faster code, which is good
  94. <Hirato> also with virtual functions, pure abstract prototypes can also be significantly optimised by the compiler, graphitemaster can explain taht black magic to you
  95. <thedardanius> of course, this depends
  96. <thedardanius> the compiler never inlines everything you tell it to
  97. <thedardanius> it can decide on its own if it should
  98. <quin> as i said, if it that much of a problem eihrul would have fixed it
  99. <quin> he understands this stuff far more than anyone
  100. <thedardanius> IM NOT TALKING ABOUT THE PROBS
  101. <graphitemaster> two interesting tricks to doing free virtual function calls
  102. <thedardanius> IM TALKING ABOUT POSSILE OPTIMIZATIONS
  103. <thedardanius> SRSLY
  104. <thedardanius> FACK
  105. <thedardanius> THIS
  106. <thedardanius> im off
  107. <Hirato> I'm well aware of that, but in the few instances templates are used in our code, the functions are very small and won't gain us anything
  108. <thedardanius> true
  109. <thedardanius> i agree with you
  110. <thedardanius> but templates used in alrger engines are usually quite large in size
  111. <graphitemaster> this is a very interesting trick:
  112. <graphitemaster> sometype localobject;
  113. <graphitemaster> sometype* localptr = &localobject;
  114. <thedardanius> yeah
  115. <graphitemaster> since that object is allocated on the heap and has a known type to the compiler, it can optimize away the entire vtable
  116. <thedardanius> yes
  117. <quin> can someone just ban him already? i can't do it easily with the webchat
  118. <thedardanius> this is quite smart yes
  119. <graphitemaster> ban who?
  120. <thedardanius> but graphmaster, the local object itself is created on the stack
  121. <thedardanius> since the pointer points to this adress space in the stack
  122. <quin> i'm not going to be yelled at in my own channel
  123. <graphitemaster> Anyways thedardanius gcc and clang and MSVC are getting realy good at inlining things, infact they're inline machines
  124. <thedardanius> I know
  125. <graphitemaster> There are some things that are hard to actually inline for the compile if its context cannot be evaluated at compile-time
  126. <thedardanius> I also dont contend the cube engine is wrong or sth
  127. <Hirato> I'll let graphitemaster do it when he's done \o/
  128. <thedardanius> the cube engine ie VERY efficient and well coded
  129. <graphitemaster> The cube engine is one of those things that does inline well, and if you don't belive me just look at scale.h
  130. <thedardanius> but I just had a suggestion, a subtle change
  131. <graphitemaster> thedardanius, what was the change?
  132. <thedardanius> I just had a optimization suggestion
  133. <graphitemaster> Regarding?
  134. <thedardanius> but the cube engine is efficient
  135. <thedardanius> dont get me wrong
  136. <thedardanius> regarding overal performance
  137. <graphitemaster> are you talking about the virtual functions?
  138. <thedardanius> yeah
  139. <thedardanius> theydo slow down certain thins
  140. <quin> i think i need to work on that next article sooner rather than later
  141. <graphitemaster> a virtual function is about as slow as a function pointer
  142. <thedardanius> since you need 2 adress pointers
  143. <thedardanius> basically
  144. <thedardanius> to the vtable
  145. <thedardanius> and to the function itself
  146. <graphitemaster> right, and those lookups can easily cause a cache miss
  147. <thedardanius> true
  148. <thedardanius> but of course
  149. <graphitemaster> except the way sauer implements them this isn't the case
  150. <thedardanius> it are the devs who decide this
  151. <graphitemaster> s/sauer/cube2/
  152. <thedardanius> how does sauer implement them?
  153. <thedardanius> how ?
  154. <graphitemaster> you only suffer performance wise an additional dereference through the vtable
  155. <graphitemaster> this _used_ to be slow, but modern CPUs have BTBs and it's literally costless
  156. <thedardanius> yeah of course, the performance depens on the architecture of CPU i know
  157. <thedardanius> well like this, we can go on to higher languages
  158. <graphitemaster> and if the compiler is smart enough to evaluate the context at compile-time (which I assume it is) it's likely costless
  159. <thedardanius> true
  160. <thedardanius> some things are indeeed "costless"
  161. <thedardanius> well im going
  162. <thedardanius> cy
  163. <graphitemaster> in anycase the only thing you're paying for is the indirect call
  164. <thedardanius> what are you actually graphmaster>
  165. <thedardanius> a dev?
  166. <graphitemaster> so if it was a function pointer, a functor, or a virtual function all three of them suffer the same indirect call issue
  167. <thedardanius> that depens
  168. <Hirato> sort of, but he's very knowledgeable on CPUs and compielr stuff
  169. <graphitemaster> actually never mind the functor could be inlined right down if it was templated
  170. <graphitemaster> i.e class calling T::functor
  171. <quin> is that because of function overloading?
  172. <thedardanius> yeah go on grpahmaster
  173. <graphitemaster> anyways here's the cool thing, branch target buffers would notice the indirect calls over time and they'd get cheaper and cheaper each call untill the CPU simply knows the address in advance
  174. <thedardanius> but this requires a pointer of course
  175. <thedardanius> this pointer is the actual pointer youre using
  176. <graphitemaster> but yes I agree the whole thing could be inlined if functors were used
  177. <thedardanius> well
  178. <thedardanius> I cant change the engine
  179. <graphitemaster> since 1) they can be inline
  180. <thedardanius> eihrul should do that
  181. <graphitemaster> since 2) even if they can't be inlined, theyre DIRECT calls
  182. <thedardanius> true
  183. <thedardanius> but I would inline them
  184. <graphitemaster> but again I think the virtual function stuff is just simpler to write
  185. <thedardanius> that the whole POINT of C++
  186. <thedardanius> its easier, it covers the dark conrer of C
  187. <thedardanius> well not easier
  188. <thedardanius> but better readible
  189. <graphitemaster> I mean shit, do you think eihrul cares about supporting old CPUs where loading TWO pointers is going to be so detrimental to the speed of the game?
  190. <graphitemaster> I bet you the game wouldn't even run on systems like those to begin with :P
  191. <thedardanius> well never mind
  192. <thedardanius> Im talking about precise optimizations
  193. <thedardanius> this would be that necessary
  194. <graphitemaster> premature optimization, root of all evil
  195. <thedardanius> this aint
  196. <thedardanius> since the cube engine is quite complete
  197. <thedardanius> some FIne optimization is acceptable
  198. <graphitemaster> well optimize it, send a patch and see what the lead devs say
  199. <thedardanius> never mind
  200. <thedardanius> just wanted to get the idea across
  201. <quin> no, he'd rather tell other people what to do
  202. <thedardanius> its just a suggetsion quin
  203. <thedardanius> srsly
  204. <quin> because his point of view is the only thing that matters here
  205. <thedardanius> yeah hes the creator hes the head I know
  206. <graphitemaster> quin, you're not helping the situation
  207. <thedardanius> no
  208. <thedardanius> please
  209. <thedardanius> would you be so kind not to interfere
  210. <quin> excuse me
  211. <quin> you're in MY channel
  212. <thedardanius> so
  213. <thedardanius> its a channel
  214. <quin> go annoy the cube community
  215. <graphitemaster> thedardanius, anyways if it's that much of a concern and you want it to get headway you can make a patch
  216. <thedardanius> for chatting
  217. <thedardanius> ill try to
  218. <thedardanius> but
  219. <thedardanius> first
  220. <thedardanius> I havet to finished my own C++ engine
  221. <graphitemaster> thats why we're opensource, if you have an idea make it then tell us about it
  222. <thedardanius> yeah exaclty
  223. <thedardanius> what I wanted to do
  224. <graphitemaster> everything sounds fine when it comes out of your mouth, doesn't mean it's true
  225. <thedardanius> together we can improve the situation
  226. <thedardanius> well
  227. <graphitemaster> I can talk a pile of shit too, and I do, I need to stop doing that :P
  228. <thedardanius> ;p
  229. <thedardanius> lets quit this
  230. * quin sets ban on *!*@80.60.172.127
  231. <thedardanius> f
  232. * quin has kicked thedardanius from #redeclipse (Bye)
  233. <graphitemaster> quin, >_>
  234. * quin sets ban on *!*@*/80.60.172.127
  235. <Hirato> awh, wanted to kick him with "dong dong bannu"
  236. <Hirato> "costless", like his mom, amirite? :D
  237. * quin sets ban on *!*@*/ip.80.60.172.127
  238. * quin removes ban on *!*@*/80.60.172.127
  239. <graphitemaster> I don't think he even warrented a ban
  240. <quin> people like that are worthless
  241. <Hirato> he yeleld at me and disrespected quin's authority
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement