samcv | icc does seem to be faster | 01:12 | |
.tell brrt i'm getting lots of integer truncation and failing some integer tests in nqp using the ICC | 01:23 | ||
yoleaux | samcv: I'll pass your message to brrt. | ||
samcv | may or may not be related | 01:24 | |
these are the errors gist.github.com/samcv/daf1b850727a...64b10cf471 | 01:25 | ||
s/errors/warnings | |||
not ok 1 - denormal 5e-324 is recognized and is not 0; not ok 7 - denormal 5e-324 is recognized and is not 0 (Uni) in t/nqp/115-nums.t | 01:27 | ||
not ok 98 - super small result from div_In work in t/nqp/060-bigint.t | |||
Geth | MoarVM: 42d5d0220c | (Samantha McVey)++ | build/setup.pm Add Intel C Compiler as an option to Configure.pl This is a copy of gcc except with -wd858 which supresses a warning that const on a return type is meaningless (warning doesn't show up on other compilers). |
01:33 | |
01:39
bisectable6 joined
|
|||
japhb | samcv: But is icc's warning *correct*? | 01:45 | |
Meaning, should we fix the codebase rather than silencing the warning? | |||
geekosaur | const on a return type means something different in gcc, iirc | 01:48 | |
actually, no. seems it's both meaningful and useful, but only relatively recently. I was thinking of __attribute__ (const) | 01:50 | ||
samcv | japhb: i'm not sure | 01:51 | |
geekosaur | stackoverflow.com/questions/871633...nst-value# (links to a duplicate which doesn't include all of the discussion) | 01:52 | |
samcv | though i'm more concerned with the warning in the gist gist.github.com/samcv/daf1b850727a...64b10cf471 | ||
and that it fails some tests :\ though that could be unrelated | |||
geekosaur | warning seems correct on 64-bit, unless you're doing the mixed-model thing a pointer is 64 bits, not 32 | 01:53 | |
oh, sorry, code actually expects that | 01:54 | ||
so warning is correct but truncation is wanted there | |||
samcv | i'm guessing maybe something Zoffix did make it not portable or something | 01:56 | |
gonna run a full rakudo spectest now | |||
geekosaur | no, it's portable, and it's being done appropriately and explicitly | ||
samcv | no i mean other code | 01:57 | |
geekosaur | well, technically you;d mask off the high bits I guess just to be completely clear, but that's a bit wasteful | ||
samcv | not the one i linked about the warning, but the changes zoffix made to fix denormals, i'm guessing it may not work for all compilers. i'm not sure | ||
yeah | |||
geekosaur | the denormals may be a different issue I was going to comment on next | ||
samcv | ok :) | ||
geekosaur | gcc etc. these days assume you want full internal precision from floating point | ||
icc may not | 01:58 | ||
there;s some gcc options that will disable full precision, which may help with diagnosis; I'm trying to dig them up | 01:59 | ||
samcv | looking at the manpage. there's Set internal FPU precision to 24 bit significand, and 53 bit or 64 bit | 02:00 | |
^ talking about ICC | |||
geekosaur | huh. maybe icc also uses full precision by default | 02:03 | |
and in fact it looks like gc may still not do so; I thought that had changed, but sse2 and later more or less force it anyway. -ffast-math would get you 870 bit precision in that case | |||
samcv | hmm so it passes spectest | 02:04 | |
geekosaur | which you might try with gcc to see if it then has the same or similar test failures. (might also need to disable -msse2 or whatever) | ||
er, 80 bit precision | |||
02:04
Merfont joined
|
|||
geekosaur | some discussion about floating point stackoverflow.com/questions/729586...ode-in-gcc | 02:06 | |
samcv | also it could be due to it using icc's math libraries | ||
which i think it uses | |||
i'm gonna try the -pc80 flag to icc and see if that changes anything | 02:07 | ||
nope. still the same | 02:08 | ||
5e-324 is 0 though so maybe something is weird | 02:09 | ||
geekosaur | that's using higher precision than gcc does | 02:10 | |
samcv | well it works fine on clang and gcc with MoarVM's setup | 02:11 | |
geekosaur | but it looks like higher precision in the exponent, not the mantissa | ||
samcv | hm | ||
it could be in strtod maybe? | 02:13 | ||
geekosaur | conceivable but I'd say it's a fairly severe bug because 5e-324 shouldn't even be possible with (double) | 02:14 | |
samcv | so the test is maybe wrong? | ||
geekosaur | at least I think it's not; not sure where float limits are in gcc | ||
samcv | geekosaur: ok it does seem to be strtod that is returning a different result | 03:33 | |
04:18
evalable6 joined
|
|||
samcv | 5e-308 works but higher exponents don't | 04:30 | |
04:34
Zoffix joined
|
|||
Zoffix | 5e-324 is possible. It's a denormal, where portion of mantissa is used for the exponent | 04:34 | |
en.wikipedia.org/wiki/Denormal_number | |||
geekosaur | oh, that would break strtod, yes | 04:35 | |
if it's not expecting that | |||
Zoffix | "<samcv> you are likely interested in problems with denormal support on the intel c compiler".... | 04:36 | |
Not really. | 04:37 | ||
04:37
Zoffix left
|
|||
samcv | yeah i think that may be correct | 04:39 | |
ok it sets errno to ERANGE and i guess we don't check errno | 04:49 | ||
05:24
domidumont joined
|
|||
samcv | ok yay i fixed it | 05:27 | |
05:30
domidumont left
|
|||
Geth | MoarVM: 2052888eba | (Samantha McVey)++ | build/setup.pm Fix handling of denormals for Intel C Compiler Without setting the `-fp-model precise -fp-model source` CFLAGS code isn't compiled to handle denormal floating point values. This caused a few nqp tests for denormals to fail. |
05:30 | |
05:30
domidumont joined
|
|||
samcv | geekosaur: thanks for the hints and helping me get this solved | 05:31 | |
06:22
domidumont left
06:31
lizmat joined
06:46
lizmat left
06:48
domidumont joined
06:59
lizmat joined,
domidumont left
07:35
zakharyas joined
07:36
zakharyas left
07:37
zakharyas joined
07:56
zakharyas left,
zakharyas joined
08:00
zakharyas1 joined
08:01
zakharyas left
08:15
zakharyas1 left
08:21
zakharyas joined
08:26
zakharyas left
08:32
zakharyas joined
09:11
zakharyas left
09:37
Redfoxmoon joined
09:48
zakharyas joined
10:44
brrt joined
|
|||
brrt | \o | 10:44 | |
nwc10 | o/ | 10:45 | |
10:47
robertle joined
|
|||
brrt | what's up with the integer truncation business | 10:54 | |
lizmat | looks like Rakudo GH #1905 is more of a moarvm issue | 11:24 | |
11:26
dogbert2 joined
11:46
lizmat left
|
|||
brrt | .tell samcv that's normal, that's just what dynasm does | 12:11 | |
yoleaux | brrt: I'll pass your message to samcv. | ||
13:23
ggoebel joined
14:05
zakharyas left,
zakharyas joined
14:09
zakharyas left
14:57
domidumont joined
15:02
brrt left
15:29
brrt joined
15:35
domidumont left
15:54
ggoebel left
16:00
robertle left
16:08
lizmat joined
16:09
Redfoxmoon left,
Redfoxmoon joined
16:25
ggoebel joined
17:01
brrt left
17:02
brrt joined
|
|||
samcv | ok cool that's what geekosaur i think said too | 17:03 | |
yoleaux | 12:11Z <brrt> samcv: that's normal, that's just what dynasm does | ||
brrt | :-) | 17:08 | |
17:18
brrt left
18:07
ggoebel left
18:23
ggoebel joined
19:04
lizmat left,
lizmat joined
19:12
brrt joined
19:23
lizmat left,
lizmat joined
|
|||
brrt | i'm going to humbly request attention to my PR: github.com/MoarVM/MoarVM/pull/868 | 19:40 | |
timotimo | i've only read the description, but i say :+1: :P | 20:17 | |
brrt | :-) | 20:19 | |
timotimo | what's with the whitespace change in Configure.pl's line 371 | 20:20 | |
looks like the : is supposed to go in the same column as the ? above it | |||
... and the : on the line before that is also too far to the left? | |||
brrt | i dunno, that may have been cperls' work | 20:21 | |
20:26
zakharyas joined
20:29
lizmat left
20:37
brrt left
|
|||
samcv | .tell brrt it seems slower by the testing i've done | 21:24 | |
yoleaux | samcv: I'll pass your message to brrt. | ||
21:25
zakharyas left
|
|||
samcv | 4.54 before after 4.60 for this thing | 21:32 | |
dd if=/dev/urandom bs=100 count=800000 | base64 > /tmp/stuff; perl6 -e 'use nqp; my $hash := nqp::hash(); my @file = "/tmp/stuff".IO.slurp.lines; my $t1 = now; for @file { nqp::bindkey($hash, $_, 1) };my $t2 = now; for @file { nqp::atkey($hash, $_) }; ' | |||
MasterDuke | we should get that moarvm benchmark page up and running again | 22:45 | |
...which i can never remember the address of | 23:07 | ||
huggable: bench | 23:23 | ||
huggable | MasterDuke, github.com/japhb/perl6-bench | ||
MasterDuke | japhb: ping | 23:41 | |
japhb | Pong | 23:46 | |
You wanted to know something about perl6-bench? | 23:47 | ||
I wrote the code there; for a while jnthn was running it daily on one of his servers and posting the results, but I've not done that. | |||
Note that many perl6-bench tests -- especially the microbenchmarks -- are probably wildly out of date WRT to the current state of Rakudo optimization (or lack thereof, as the case may be). | 23:49 | ||
MasterDuke | so far i've had to add a .cache on line ~75 of bench | 23:54 | |
but things seem to be running otherwise | |||
i also removed most entries from components.json, but that's just because i only wanted to run it for moarvm and perl5 | 23:55 | ||
hm, bunch of Configure.pl errors, might be i need some perl5 module installed though... | 23:58 | ||
japhb | Yeah, that I would believe. | ||
MasterDuke | build::setup isn't a core module? | 23:59 | |
japhb | BTW, you don't *have* to remove things from components, the driver script is relatively forgiving in different ways to indicate you only want to work with a subset of available engines/builds. |