|
00:25
vendethiel joined
00:49
vendethiel joined
02:23
vendethiel joined
02:24
colomon joined
02:48
ilbot3 joined
03:01
vendethiel joined
03:35
vendethiel joined
04:10
vendethiel joined
04:33
vendethiel joined
05:02
vendethiel joined
05:55
vendethiel joined
06:22
vendethiel joined
07:11
vendethiel joined
07:33
colomon joined
07:36
vendethiel joined
07:43
FROGGS joined
08:14
vendethiel joined
08:37
vendethiel joined
09:01
Ven joined
09:05
vendethiel joined
|
|||
| dalek | arVM: 9fe0661 | lizmat++ | src/io/fileops.c: Symlinks always tested with lstat |
09:25 | |
| lizmat | pretty sure this is correct | ||
| FROGGS | what is the one that follows links? stat or lstat? | 09:35 | |
| stat I guess | |||
| lizmat | the one that follows links is "stat" | 09:38 | |
| lstat is the one that doesn't follow links | |||
| and the one that was used by default | |||
| FROGGS | lizmat: but, if you follow links, how can the result be a symlink? | ||
| so to ask something if it is a link you'd not have to follow | 09:39 | ||
| lizmat | hence you must use lstat() to find out whether something is a symlink | ||
| from man 2 stat: The lstat() function is like stat() except in the case where the named | 09:40 | ||
| file is a symbolic link; lstat() returns information about the link, | |||
| while stat() returns information about the file the link references. | |||
| FROGGS | so, stat follows | 09:41 | |
| lizmat | that's what I said, ? | ||
| FROGGS | ahh, yes | ||
| it all makes sense now that I re-read slowly :D | |||
| jnthn | :) | 09:42 | |
| lizmat | it's confusing and counter-intuitive, at least to me | ||
| FROGGS | it is | ||
| I'll just blame the crying baby nearby | |||
| lizmat | anyway, with these changes | 09:43 | |
| if a symlink points to a directory | |||
| then .d is true (it used to be false) | |||
| FROGGS | lizmat++ | 09:44 | |
| jnthn | It's quite incredible how costly missed branch predictions are. | 09:54 | |
|
09:56
dalek joined
|
|||
| jnthn is noting this after seeing numbers from a demo he's prepared for $dayjob teaching | 09:57 | ||
| Tells us that everywhere we can eliminate polymorphic, and especially megamorphic, things, we're onto a winner, though. | |||
| nwc10 | jnthn: curiously, when we tried adding __builtin_expect() to various "we know it's this way" paths in the perl core C code, we didn't manage to measure anything | 09:58 | |
| which seems to imply that the branch predictor on the CPUs we tested on are pretty good at figuring out the obvious ones | 09:59 | ||
| jnthn | *nod* | ||
|
09:59
Ven joined
|
|||
| jnthn | Yeah, I was going through an array of random true/false values and doing a conditional in the branch, which is, I guess the extreme case | 10:00 | |
| nwc10 | so, seems that your strategy is important - CPUs are doing better than humans at predicting branches when it's possible. Hence we need to reduce the number of branches | ||
| jnthn | Well, other thing is that the branch predictor isn't infinitely large either. | ||
| nwc10 | it's not? :-( | 10:01 | |
| [yes, I know I'm being silly] | |||
| actually, second order maybe, but this seems to imply that a guard clause that is very rarely taken is effectively negligable CPU overhead. | 10:02 | ||
| [as long as it remains in the cache] | |||
| and also "RAM is cheap, but there aren't slots on the motherboard for more CPU cache" | 10:03 | ||
| FROGGS | not anymore | ||
| nwc10 | good point :-) | ||
| lizmat | gist.github.com/lizmat/c237a42a812e5f10e412 # Moar changes for adding an "lstat" op, comments ? | 10:04 | |
| nwc10 | lizmat: I don't know enough to be useful to you here | ||
| lizmat | FROGGS jnthn might tell me :-) | 10:05 | |
| jnthn | lizmat: Looks reasonable to met. You put it just ahead of the spesh ops, which is the main thing :) | 10:07 | |
| *me | |||
| lizmat | ok :-) | ||
| FROGGS | aye, looks good | 10:08 | |
| dalek | arVM: 2d7eddb | lizmat++ | / (6 files): Add "lstat" op |
10:09 | |
|
10:12
kjs_ joined
10:17
zakharyas joined
10:22
kjs_ joined
10:28
Ven joined
10:33
Ven joined
11:30
vendethiel joined
11:36
harrow joined
12:13
vendethiel joined
12:49
vendethiel joined
12:54
Ven joined
14:34
vendethiel joined
14:42
sivoais joined
15:09
vendethiel joined
15:45
vendethiel joined
16:23
vendethiel joined
16:32
rurban joined
17:02
harrow joined
18:00
vendethiel joined
18:26
vendethiel joined
18:55
vendethiel joined
19:21
vendethiel joined
19:50
zakharyas joined
19:57
vendethiel joined
20:39
tgt joined
|
|||
| dalek | arVM/cpp: 0ee65f4 | lizmat++ | src/ (3 files): Add flag to switch between stat/lstat Many file ops now use stat, rather than lstat as before. This in preparation for an nqp::lstat op to be added in the near future. |
20:47 | |
| arVM/cpp: 9fe0661 | lizmat++ | src/io/fileops.c: Symlinks always tested with lstat |
|||
| arVM/cpp: 2d7eddb | lizmat++ | / (6 files): Add "lstat" op |
|||
|
22:04
FROGGS_ joined
22:18
pyrimidi_ joined
22:25
vendethiel joined
|
|||
| dalek | arVM/longish: 728a748 | FROGGS++ | src/6model/reprs/CStruct. (2 files): improve handling of type int on 32bit systems We can now properly obtain the size of a float on the current machine to handle attributes in C structs. Before we just read 64bits of memory of a 32bit attribute slot, which led to garbage and failings tests in NativeCall. Handling of int (C long) in CArrays is left as an excercise for the reader. |
22:48 | |
| FROGGS | gnight | 22:52 | |
| jnthn | FROGGS++ | ||
| 'night | |||
| FROGGS | jnthn: I wonder why I struggled to do exactly that in the past | ||
| it seems so obvious right now that it makes me suspicious | 22:53 | ||
| jnthn | FROGGS: Most things seem easy after you've done them ;) | ||
| FROGGS | yeah, probably... | ||
| well, gnight :o) | |||
| jnthn | o/ | 22:54 | |
|
23:00
vendethiel joined
|
|||
| timotimo | what's keeping us from making different ints and uints properly limit their contents to the given size? | 23:09 | |
| jnthn | Working out how to implement it | 23:11 | |
| Implementing what we work out | |||
| timotimo | :) | 23:13 | |