| 00:31:09 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 01:16:48 | xilo | toow toow |
| 01:56:58 | * | OrionPK quit (Read error: Connection reset by peer) |
| 01:58:30 | * | DAddYE quit (Remote host closed the connection) |
| 01:59:06 | * | DAddYE joined #nimrod |
| 02:03:19 | * | DAddYE quit (Ping timeout: 246 seconds) |
| 02:07:34 | * | q66 quit (Quit: Leaving) |
| 02:23:42 | * | zahary joined #nimrod |
| 02:24:45 | * | zahary1 quit (Read error: Connection reset by peer) |
| 02:59:36 | * | DAddYE joined #nimrod |
| 03:05:50 | * | DAddYE quit (Ping timeout: 256 seconds) |
| 04:11:04 | * | xilo quit (Ping timeout: 246 seconds) |
| 04:41:42 | * | DAddYE joined #nimrod |
| 05:28:16 | * | DAddYE quit (Remote host closed the connection) |
| 06:38:31 | * | DAddYE joined #nimrod |
| 06:38:47 | DAddYE | hi there! |
| 06:39:12 | DAddYE | any advice how to improve performance: https://github.com/daddye/node.nim ? |
| 06:39:38 | DAddYE | aka I need some general tips to improve performance, since you guys are much more experienced than me ;) |
| 07:09:26 | * | Araq_ joined #nimrod |
| 07:50:42 | * | Araq_ quit (Read error: Connection timed out) |
| 07:52:41 | * | Araq_ joined #nimrod |
| 08:26:37 | * | DAddYE quit (Ping timeout: 276 seconds) |
| 08:45:39 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) |
| 09:19:22 | * | EXetoC joined #nimrod |
| 09:21:41 | EXetoC | The ubuntu forums were hacked, and I had an account there? -.- |
| 09:57:32 | * | Araq_ joined #nimrod |
| 10:08:14 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) |
| 10:52:02 | * | Araq_ joined #nimrod |
| 11:00:57 | * | q66 joined #nimrod |
| 11:18:15 | * | Araq_ quit (Read error: Connection timed out) |
| 11:19:18 | * | Araq_ joined #nimrod |
| 11:54:32 | * | Araq_ quit (Read error: Connection timed out) |
| 11:55:18 | * | Araq_ joined #nimrod |
| 12:12:31 | * | Araq_ quit (Read error: Connection timed out) |
| 12:13:18 | * | Araq_ joined #nimrod |
| 12:43:55 | * | Araq_ quit (Read error: Connection timed out) |
| 12:45:16 | * | Araq_ joined #nimrod |
| 13:09:44 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) |
| 13:12:33 | * | Trixar_za joined #nimrod |
| 13:41:09 | * | Araq_ joined #nimrod |
| 13:48:38 | * | xilo joined #nimrod |
| 13:48:53 | * | Trixar_za quit (Ping timeout: 245 seconds) |
| 13:55:15 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) |
| 14:01:47 | * | Trixar_za joined #nimrod |
| 14:22:56 | * | Trixar_za quit (Ping timeout: 268 seconds) |
| 16:33:22 | * | DAddYE joined #nimrod |
| 16:51:41 | dom96 | hi |
| 16:51:50 | dom96 | EXetoC: Yeah, I had an account there... |
| 16:52:00 | dom96 | can't remember which password I used |
| 16:52:06 | dom96 | so yeah... |
| 17:12:53 | EXetoC | :> |
| 17:22:41 | * | jbe_ joined #nimrod |
| 17:23:12 | Araq | ping zahary |
| 17:24:09 | dom96 | hi jbe_ |
| 17:24:12 | dom96 | hi Araq |
| 17:24:22 | Araq | hi dom96 |
| 17:24:54 | jbe_ | greetings noble wizards |
| 17:25:02 | Araq | hi jbe_ |
| 17:25:27 | jbe_ | :) |
| 17:37:46 | * | Mat2 joined #nimrod |
| 17:37:48 | Mat2 | hello |
| 17:43:15 | Araq | hi Mat2 |
| 17:47:12 | Mat2 | hi Araq and hello @ all |
| 18:09:26 | Mat2 | DAddYE: You can use sets and let the compiler optimizate the bit-shiftings out because for some Intel cpu's these are slow operations |
| 18:11:40 | Mat2 | otherwise the TCP protocol is known not to be the best-one performance wise dependent of usage |
| 18:12:25 | Mat2 | (I do not know what server application you have in mind) |
| 18:40:47 | DAddYE | thanks Mat2! |
| 18:41:42 | DAddYE | Mat2: do you mean the bitshifting of http_parser? |
| 18:44:33 | Mat2 | yes |
| 18:45:04 | Araq | I can't imagine bitshifting is in any way measurable |
| 18:45:35 | Araq | it's 5 cycles vs 1 or something on some old cpus, a single cache miss is much worse |
| 18:46:31 | Mat2 | on these older cpu's bit-shifting are so called vector operations which block the pipelines |
| 18:47:44 | Araq | on old pentiums only the u-pipe can process them and not the v-pipe (or the other way round) |
| 18:48:04 | Araq | but again, I can't imagine it's measurable today |
| 18:48:47 | Mat2 | your right, except for my i3 core which is affected from this |
| 18:48:56 | Mat2 | also Intel Atom |
| 18:49:20 | Mat2 | and Pentium 4 |
| 18:50:22 | Araq | interesting |
| 18:51:11 | Mat2 | the clock cycles are a bad orientation for these kind of problems because pipline-stalls affect also prefetching and this can cost much more clock cycles |
| 18:51:51 | Araq | well I didn't know it causes pipeline stalls |
| 18:52:25 | Mat2 | http://www.agner.org/optimize/ |
| 18:53:14 | Araq | yeah I know this |
| 18:56:43 | Mat2 | I'm not sure about the exact source for this behaviour but I can measure it on some processors. Also the GNU C compiler specially include a code-optimization for this so it must be relevant |
| 18:58:12 | Mat2 | another pitfall can be the use of lea and xchg |
| 19:00:12 | Mat2 | I think these instructions result in some sort of internal code-serialisation (specially xchg seem to generate problems for register remapping on some CPU's) |
| 19:01:30 | Mat2 | all of this isn't handled in the official optimization guides |
| 19:02:12 | Araq | xchg is implicitly atomic iirc |
| 19:02:21 | Araq | so yeah I wouldn't use it |
| 19:17:13 | Mat2 | ok, I found the reasom. Some Intel cpu's do not have a barrel-shifter unit anymore, this means shift and rotate instructions must be emulated though integer operations. Because the Out-Of-Order engines archive high "thoughports" there is no unit left free for insertions (dependent on the instuction mix) generating pipeline stalls |
| 19:17:20 | Mat2 | ^reason |
| 19:17:34 | Mat2 | ^thoughputs |
| 19:33:01 | DAddYE | quick info, can we use passc in the nimfile.cfg ? |
| 19:33:10 | Araq | sure |
| 19:33:31 | Araq | gah, why can't aporia render 24'u32 properly? |
| 19:33:56 | DAddYE | Araq: sure -> for me? |
| 19:34:09 | Araq | DAddYE: yes |
| 19:35:13 | DAddYE | Araq: cool! Thanks! |
| 19:40:47 | NimBot | Araq/Nimrod master 9051a01 Araq [+4 ±0 -0]: first steps to a new evaluation engine |
| 19:40:47 | NimBot | Araq/Nimrod master a7aa473 Araq [+0 ±1 -0]: Merge branch 'master' of github.com:Araq/Nimrod |
| 19:43:36 | EXetoC | yay, bits! |
| 19:48:16 | * | reactormonk quit (Ping timeout: 240 seconds) |
| 19:58:30 | NimBot | Araq/Nimrod master 2dd9357 Araq [+0 ±5 -0]: added macros.genSym |
| 19:58:40 | Araq | dom96: here you go |
| 20:01:56 | dom96 | thx |
| 20:30:46 | * | Associat0r joined #nimrod |
| 20:30:46 | * | Associat0r quit (Changing host) |
| 20:30:46 | * | Associat0r joined #nimrod |
| 20:35:22 | NimBot | Araq/Nimrod master 950597b jbe [+0 ±1 -0]: export pointer types for SDL event objects |
| 20:35:22 | NimBot | Araq/Nimrod master 29edd4a Araq [+0 ±1 -0]: Merge pull request #527 from jbe/master... 2 more lines |
| 20:46:50 | EXetoC | emulating field access with procs sure is trivial. sometimes you might accidentaly assign something to a field returned by the getter though, rather than calling `x=`, if both are defined |
| 20:47:32 | EXetoC | It's just a matter of renaming one of them though |
| 20:47:40 | Araq | I can't follow |
| 20:47:52 | Araq | if you don't return 'var T' you can't assign to the getter |
| 20:48:05 | Araq | btw just fixed your named argument bug |
| 20:48:17 | Araq | took longer to download your code than to fix it |
| 20:49:12 | EXetoC | that's great |
| 20:54:29 | EXetoC | Araq: no not directly, but if you have "proc x(o: T): U =..." and "proc `x=`(o: T, val: U) =..." then it's very easy to do "o.x.foo = 42" by mistake. it's quite subtle |
| 20:55:38 | EXetoC | I've been thinking of some possible solutions which I think would involve compiler magic, but maybe it's best to rename one of the symbols except maybe when the type in question is simple |
| 20:56:31 | Mat2 | ciao |
| 20:56:47 | * | Mat2 quit (Quit: Verlassend) |
| 20:56:55 | Araq | o.x.foo works exactly how it should work |
| 20:57:56 | Araq | o.x = (o.x.foo = 42) ? how else should it work? |
| 21:08:04 | NimBot | Araq/Nimrod master ffaa0b2 Araq [+0 ±4 -0]: fixes #544 |
| 21:08:04 | NimBot | Araq/Nimrod master 14158fc Araq [+13 ±1 -0]: fixes #531 |
| 21:08:04 | NimBot | Araq/Nimrod master d0078b1 Araq [+0 ±1 -0]: Merge branch 'master' of github.com:Araq/Nimrod |
| 21:15:57 | EXetoC | I'm just saying that it might be confusing to give them the same name, and it wasn't a problem for me until recently |
| 21:18:40 | EXetoC | since it's very different from direct field access in this case, but the user might not always notice. it's just an observation, and I might try to avoid naming getter and setter pairs like that |
| 21:19:50 | Araq | well please give your example |
| 21:20:08 | Araq | it might also be a bug that the compiler doesn't complain |
| 21:20:29 | Araq | as o.x() is not an l-value in general |
| 21:20:53 | dom96 | huh? o.x = 42 is the same as o.x.foo = 42 in that case? |
| 21:21:22 | Araq | dom96: no ... |
| 21:21:36 | dom96 | oh good. |
| 21:28:24 | EXetoC | 'foo' might be a reference though, but yeah |
| 21:28:58 | Araq | well if it's a reference you get the right semantics |
| 21:34:07 | Associat0r | http://www.reddit.com/r/programming/comments/1iyp6v/is_there_a_really_an_empirical_difference_between |
| 21:36:23 | EXetoC | yes, but the original will still exist at that point, just that it won't be as common. anyway, I'll create an example soon |
| 21:36:37 | Araq | Associat0r: and now you know why nimrod is style insensitive |
| 21:36:41 | EXetoC | tests/manyloc/named_argument_bug. oh man :p |
| 21:36:46 | Araq | but that doesn't end the wars unfortunately either |
| 21:36:55 | Araq | now it becomes TTime vs Time |
| 21:37:49 | Associat0r | Araq: .NET Framework guidelines had some good guidelines for those cases |
| 21:38:25 | Araq | .NET framework's guidelines are broken |
| 21:38:46 | Araq | public MyEnum MyEnum { get; } // gah, kill it already |
| 21:39:42 | EXetoC | silly |
| 21:40:02 | EXetoC | not that I know anything about .NET, but still |
| 21:40:30 | Associat0r | well that's because they use PascalCase for public methods there |
| 21:41:29 | Araq | well _privateFields are ugly too |
| 21:41:59 | Associat0r | true but better than m_privateFields |
| 21:42:00 | dom96 | hrm, does Ada also use the 'T' prefix? |
| 21:42:16 | Araq | dom96: nope |
| 21:42:25 | dom96 | how does it work then? |
| 21:42:32 | Associat0r | btw I wouldn't use T prefix for types |
| 21:42:48 | dom96 | do people just avoid clashes by not naming their variables the same thing as their types? |
| 21:42:58 | Araq | dom96: yeah |
| 21:43:18 | Araq | Associat0r: actually T/P is about value vs reference types a convention coming from Delphi |
| 21:43:32 | EXetoC | would've been less of an issue had underscores been significant |
| 21:43:47 | Araq | so yeah the T stands for "value type" -.- |
| 21:44:17 | EXetoC | or maybe you could just do "var vrect: TRect" |
| 21:44:43 | Araq | you can do 'var rect: Rect' already, EXetoC btw |
| 21:45:00 | EXetoC | oops, not TRect |
| 21:45:02 | EXetoC | right |
| 21:45:35 | Araq | but not many people know that and it causes problems anyway |
| 21:47:05 | EXetoC | var int = 0. oh yeah look at that |
| 22:05:26 | * | OrionPK joined #nimrod |
| 22:10:51 | OrionPK | anyone going in for an Ubuntu Edge? |
| 22:11:16 | dom96 | $600 no way. |
| 22:11:33 | OrionPK | well, for an unlocked phone that doubles as a desktop computer |
| 22:11:43 | OrionPK | $600 is (sickeningly) not that much for an unlocked smartphone |
| 22:13:11 | EXetoC | how do I dereference a 'ref' type? the dot operator has taken care of that before |
| 22:13:20 | Araq | r[] |
| 22:13:32 | EXetoC | ok |
| 22:20:05 | EXetoC | Araq: https://gist.github.com/EXetoC/6075116 |
| 22:20:24 | EXetoC | it might make more sense when the "getter" and "setter" doesn't even correspond to an actual field |
| 22:21:08 | Araq | how is this confusing? |
| 22:21:23 | Araq | what should bar.thing.x mean instead? |
| 22:31:10 | EXetoC | it's easy to lose track of what's an actual field access and what isn't, that's all I've been saying |
| 22:32:35 | Araq | oh alright |
| 22:48:19 | EXetoC | and even primitives can be made to look like aggregates, so "getThing/`thing=`" seems like a good compromise |
| 22:49:12 | Araq | I'd go with thing/setThing |
| 22:54:59 | EXetoC | yeah, no need to overuse `x=` |