[00:00] *** lizmat joined
[01:00] *** lizmat joined
[01:47] *** ilbot3 joined
[06:33] *** domidumont joined
[06:36] *** Ven joined
[06:38] *** Ven joined
[06:38] *** domidumont joined
[08:21] *** leont joined
[08:25] *** lizmat_ joined
[08:52] <leont> jnthn: MVM_SPESH_OSR_DISABLE=1 doesn't fix it

[09:07] *** tomboy64 joined
[09:11] <tomboy64> i have a suggested patch for moarvm's Configure.pl: https://bpaste.net/show/e6d9849d7d77

[09:11] <tomboy64> also, is lua a build-time only dependency?

[09:12] <lizmat> tomboy64: afaik, jnthn will accept PR's on moarvm  :-)

[09:12] <tomboy64> :)

[09:13] <tomboy64> i'd still like some feedback on it here

[09:14] <lizmat> I assume ExtUtils::PkgConfig is P5 core ?

[09:15] <timotimo> yeah, lua is only needed at build-time, and even then we could distribute the files it spits out with a release or in a distro package

[09:15] <tomboy64> hmm. actually i don't think so. at least my distro (gentoo) lists it as a cpan package

[09:16] <tomboy64> as a regular cpan package

[09:16] <tomboy64> timotimo: that's not necessary.

[09:16] <timotimo> that's bad; so far we've only depended on core perl5 - and a really old version of perl5 at that

[09:16] <lizmat> so that would add a prereq

[09:17] <tomboy64> okay. could i depend on native pkg-config then?

[09:19] <tomboy64> because otherwise i wouldn't get a path like -I/usr/lib64/libffi-3.2.1/include

[09:20] <timotimo> you could; that's easier to have a fallback for, IMO

[09:20] <timotimo> a shell-out failing is easier than a module use failing, i mean

[09:21] <tomboy64> :-} how do i do a shell call in perl?

[09:22] <timotimo> in perl5 i don't know ... but our configure stuff already does lots of shelling out to figure out things regarding the C compiler

[09:23] <psch> tomboy64: system() for the exit code and exec() for the output iirc

[09:23] <tomboy64> psch: so i would effectively run things twice?

[09:24] <psch> tomboy64: well, if you actually need both (as in, the output carries different information than the exit code), yes

[09:24] <timotimo> why doesn't perl5 core have something for that purpose?

[09:24] <timotimo> er, why *wouldn't*

[09:25] <timotimo> as in: it's gotta have that, right? otherwise it'd be strange

[09:26] <psch> http://www.perlhowto.com/executing_external_commands

[09:26] <psch> exec() probably is the wrong tool

[09:26] <psch> i'm not really a perl5 programmer... :)

[09:27] <timotimo> huh. how do you figure out if a program fails later on with the open approach?

[09:27] <timotimo> i see it's easy to figure out if/that it couldn't be started, as in: binary doesn't exist

[09:28] <timotimo> maybe you close the file handle you opened and that then has a return value?

[09:29] <tomboy64> thanks guys

[09:30] <tomboy64> that should actually make things work

[09:43] *** leont joined
[10:07] *** Ven joined
[10:24] *** Ven joined
[11:22] *** leont joined
[11:24] *** flaviusb joined
[12:50] *** leont joined
[13:53] *** Ven joined
[14:30] *** zakharyas joined
[14:46] *** Ven joined
[15:22] *** zakharyas joined
[17:11] *** Ven joined
[17:37] <timotimo> https://gcc.gnu.org/wiki/AutoFDO  -  are we interested in this at all?

[17:39] <lizmat> with the rate of disappearing gcc support on the various distributions, I wonder how much it would be worth

[17:40] <timotimo> oh, is clang seriously replacing gcc in some places?

[17:40] <timotimo> that'd be catastrophic for moarvm build times

[17:41] <arnsholt> Are there any Linux distros replacing GCC with clang?

[17:41] <arnsholt> I think I've heard of fBSD talking about something like that, but not any Linux distros

[17:45] <lizmat> well, OSX comes to mind

[17:46] <timotimo> well, apple is heavily investing into llvm and clang anyway

[17:50] <leont> From what I head clang is also becoming the standard in BSD land, but in Linux not so much

[17:51] <leont> It doesn't help that recent g++ and clang++ aren't compatible :-/

[17:55] <arnsholt> Yeah, and OS X

[17:55] <arnsholt> They've swapped out a fair bit of software due to GPL3

[17:57] <leont> Quite

[18:19] <geekosaur> fbsd replaced gcc with clang as of 9.3-RELEASE and 10.0-RELEASE

[18:22] <BinGOs> 9.x has clang as well as gcc and the default compiler (cc) is gcc

[18:22] <BinGOs> but yeah, gcc was gone from 10.0 and cc was clang

[18:26] <geekosaur> sorry I meant 9.4 not 9.3 which was still gcc

[18:29] <geekosaur> and it looiks like it's not actually released yet despite references to it around the net :/ thought it had happened already. in any case 9-STABLE has gone clang for the base system and the next release will use it

[18:32] <orbus_> out of curiosity, why is it that moarvm builds so much slower on clang?  have the specific pain points ever been identified?

[18:32] <timotimo> it's interp.c

[18:33] <timotimo> it has a gigantic amount of named labels

[18:34] <arnsholt> Have we reported it to the clang bugtracker?

[18:34] <timotimo> no clue. i've done nothing like that

[18:34] <orbus> it has a lot, but it doesn't seem like *that* many

[18:35] <timotimo> clang certainly takes its time compiling it

[18:35] <timotimo> we should probably do individual timings to make sure it is really interp.c that is the problematic one

[18:35] <timotimo> and not just everything being equally slower

[18:35] <timotimo> https://travis-ci.org/MoarVM/MoarVM  -  here you can compare clang vs gcc

[18:36] <timotimo> 2:46 vs 9:42

[18:36] <timotimo> 2:55 vs 10:47

[18:37] <orbus> hrm

[18:37] <orbus> I did a build on freebsd with clang a while back

[18:37] <orbus> I don't remember it being super duper slow

[18:37] <orbus> but maybe I just walked away while it was compiling

[18:38] <geekosaur> clang does have its known pain points re compile speed

[18:38] <geekosaur> one of the worst examples is part of llvm, so they definitely know about it

[18:42] <orbus> maybe they just figure people will throw more hardware at it if compile time matters to them

[18:43] <timotimo> or, you know, just develop on linux or windows :)

[18:46] <orbus> hmm

[18:46] <orbus> looks like stock linux kernel won't build on clang

[18:47] <orbus> but there's a project producing patches that looks they can make it work

[18:47] <timotimo> that's useful

[18:47] <orbus> but probably why linux distros aren't moving towards it

[18:47] <timotimo> yeah

[18:50] <orbus> this was from last year but I'm not sure that the situation's changed much

[18:50] <orbus> http://www.phoronix.com/scan.php?page=news_item&px=llvm-clang-linux-kernel-2015

[19:02] <geekosaur> I think a lot of the air got sucked out of that project whern gcc fixed its performance issues in 4.9

[19:02] <geekosaur> after Linus caught it doing some pathetically stupid things

[19:03] <timotimo> hah, our code generator and optimizers are like that, too ... in some parts :)

[19:03] <geekosaur> but we're not on version 4.9 :)

[19:03] *** cognominal joined
[19:03] <timotimo> with something as gigantic as a compiler, it's hard to look at every nook and cranny unless you have good tests that you can look at the compiler with

[19:38] <masak> another blog post for all you GC lovers out there: http://v8project.blogspot.se/2016/04/jank-busters-part-two-orinoco.html

[19:47] *** Ven joined
[19:52] <moritz> masak: good read, thanks

[20:53] *** leont joined
[21:30] *** leont_ joined
[22:28] *** leont_ joined