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
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*
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
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
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
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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!