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