| buggable | 🎺🎺🎺 It's time for the monthly Accidental /win Lottery 😍😍😍 We have 2 ballots submitted by 1 users! DRUM ROLL PLEASE!... | 00:00 | |
| And the winning number is 3! Congratulations to [Coke]! You win a roll of duck tape! | |||
|
00:03
harrow left
00:17
harrow joined
01:46
ilbot3 left
01:57
ilbot3 joined
03:44
AlexDaniel left,
nine left
03:46
benchable6 left,
coverable6 left
03:47
coverable6 joined,
benchable6 joined,
shareable6 left,
squashable6 left,
greppable6 left
03:48
committable6 left
04:25
Kaiepi joined
04:44
committable6 joined,
greppable6 joined
04:45
squashable6 joined
05:04
brrt joined
|
|||
| brrt | good hi #moarvm | 05:05 | |
| .seen jnthn | |||
| yoleaux | I saw jnthn 30 May 2018 21:01Z in #perl6-dev: <jnthn> nine++ for not taking the nqp:: shortcut outside of the Rakudo repo :) | ||
| samcv | good hi brrt :) | 05:06 | |
| brrt | good hi samcv | 05:13 | |
| i'll take a look at those coverity things later :-) | 05:19 | ||
| samcv | cool :) | 05:58 | |
|
06:20
domidumont joined
06:26
domidumont left
06:27
domidumont joined
06:57
Ven`` joined
|
|||
| Geth | MoarVM: ff312c4cf8 | (Bart Wiegmans)++ | 4 files [JIT] Fixes for coverity - use MVM_ARRAY_SIZE, which I want to promote to a 'global' macro at some point - add a 'tiny bitmap' function for single MVMuint64 bitmaps - precompute the size of the templates array (so we can't overflow), although we couldn't in reality (the templates array is equal in size to the defined opcodes, and non-defined opcodes can't be present in the spesh graph) |
07:02 | |
|
07:08
brrt left
07:19
AlexDaniel joined
07:26
Ven`` left,
Ven`` joined
|
|||
| samcv | brrt++ | 07:30 | |
|
07:47
nine joined
07:49
yoleaux left
07:50
undersightable6 left,
undersightable6 joined
07:52
Ven`` left
08:01
zakharyas joined
|
|||
| Redfoxmoon | Is cross compilation supported at all? | 08:14 | |
|
08:55
Ven`` joined
09:19
AlexDaniel left
|
|||
| lizmat | Redfoxmoon: not at the moment, afaik, but I know of some people thinking of getting this off the ground this year | 09:30 | |
| Redfoxmoon | hmmmm | ||
| I see, does the interpreter need to run while building? | 09:31 | ||
| lizmat | if you're talking about Moar, I don't think so | 09:32 | |
| Redfoxmoon | Yeah, that's interesting | ||
| lizmat | in the case of Perl 6: well, parts of Perl 6 are written in Perl 6 | 09:33 | |
| Redfoxmoon | heheh. | ||
| lizmat | but you could argue that it is still nqp running when compiling Perl 6 | ||
| Redfoxmoon | so you could in theory cross compile moarvm and use it to build perl 6 natively? | ||
|
09:49
yoleaux joined
09:51
AlexDaniel joined
10:01
AlexDaniel left
|
|||
| lizmat | Redfoxmoon: sorry, was afk: but yes, in theory, yes | 10:03 | |
|
10:13
brrt joined
10:14
Ven`` left
|
|||
| brrt | Redfoxmoon: note that some parts of rakudo are written as extensions to moarvm, so these would need to be crosscompiled as well | 10:16 | |
|
10:17
AlexDaniel joined
|
|||
| brrt | and there are some, too (me), who would prefer that to be not the case | 10:19 | |
| Redfoxmoon | mmmm interesting | 10:20 | |
| so in theory moarvm could be autotoolized and it would "just work" heheh. | 10:23 | ||
| except perhaps the pesky visual studio stuff | |||
| brrt | meh, i'd rather stay away from autotools if it's all the same :-) | 10:26 | |
| i mean, Configure.pl is already to complicated for what it does | |||
| oh that reminds me | 10:27 | ||
| .tell samcv that instead of per-compiler 'likely' flags, we can use '#ifdef _MSCV_VER' and friends | |||
| yoleaux | brrt: I'll pass your message to samcv. | ||
| brrt | the idea being that i want to move things out of Configure.pl if at all possible | 10:28 | |
| (because Configure.pl has to probe and estimate the compiler, whereas the compiler knows which compiler it is, so to speak) | |||
| Redfoxmoon | well, plain makefiles can be used too | 10:31 | |
| I'll have a stab at it later today / tomorrow | |||
| brrt | alright, let us know how it goes | 10:32 | |
| (what are you going to cross-compile to?) | |||
| Redfoxmoon | a new posix layer for windows | ||
| (not cygwin) | |||
| (and perl5 doesn't work there yet:-) ) | 10:33 | ||
| lizmat | ++Redfoxmoon | 10:35 | |
|
10:35
Ven`` joined
|
|||
| Redfoxmoon | lizmat, o_O? | 10:35 | |
| lizmat | well, perhaps 👍 would have been clearer ? | 10:36 | |
|
10:36
Ven`` left
10:37
Ven`` joined
|
|||
| Redfoxmoon | well it's still in pre-alpha, here midipix.org | 10:38 | |
| lizmat | Redfoxmoon: looking forward to being able to mention that Perl 6 runs on Windows with midipix :-) | 10:41 | |
| Redfoxmoon | heheh. | 10:42 | |
| that depends entirely on getting it to cross compile | |||
|
10:42
Ven`` left
|
|||
| Redfoxmoon | I saw alpine has moarvm, so there won't be issues with musl either | 10:42 | |
| which is nice. | |||
|
10:42
Ven`` joined
10:44
AlexDaniel left
|
|||
| Redfoxmoon | probably. | 10:48 | |
|
10:48
Ven`` left
10:49
Ven`` joined
|
|||
| brrt | Redfoxmoon: one potential thing to think about is libuv | 10:52 | |
| as i gather that can be a bit of work to compile on your platform | |||
| Redfoxmoon | libuv ported already | 10:53 | |
| well, "aggressively ported" -- it should work but not upstreamable:-) | |||
| brrt | oh, impressive :-) | 10:55 | |
|
10:56
Ven`` left,
Ven`` joined
|
|||
| Redfoxmoon | I mean, I am not that proud of my libuv port github.com/lalbornoz/midipix_build...ocal.patch | 10:58 | |
| heheh. | |||
| brrt | i can't see that, that's presumably private | 11:07 | |
| hmm. building CORE.setting isn't noticably faster with the stack walker than without :-( | 11:08 | ||
| within noise, i'd say | 11:14 | ||
|
11:19
Ven`` left
11:29
zakharyas left
|
|||
| Redfoxmoon | brrt, what, the github repo is public | 11:33 | |
| brrt | oh, hang on, my terminal broke up the url | 11:34 | |
| Redfoxmoon | Hah | 11:35 | |
| lizmat, well, if you're interested you could have a look at perl5 on midipix :P that way you could mention perl 6 on windows even earlier :P | 11:42 | ||
| Redfoxmoon hides | |||
|
11:50
Ven`` joined
11:56
AlexDaniel joined
12:01
brrt left
12:18
Ven`` left,
Ven`` joined
12:50
zakharyas joined
12:59
Ven` joined,
Ven`` left
13:01
Ven` left
13:04
Ven`` joined
13:37
shareable6 joined
14:53
Ven`` left
15:09
domidumont left
15:35
zakharyas left
|
|||
| samcv | .tell brrt it's not per compiler really. i mean msvc just doesn't have branch predictor hints. though i think you mean just taking out code on certain platforms? | 15:58 | |
| yoleaux | 10:27Z <brrt> samcv: that instead of per-compiler 'likely' flags, we can use '#ifdef _MSCV_VER' and friends | ||
| samcv: I'll pass your message to brrt. | |||
| samcv | ah i see | ||
| though there are other compilers other than msvc gcc and clang? | 15:59 | ||
| timotimo | like icc | ||
| if you've got the money for it | |||
| does borland still make a c compiler? | |||
|
16:16
domidumont joined
|
|||
| Redfoxmoon | there's also pcc and tcc | 16:17 | |
| Redfoxmoon runs | |||
|
18:05
brrt joined
|
|||
| brrt | . | 18:05 | |
| yoleaux | 15:58Z <samcv> brrt: it's not per compiler really. i mean msvc just doesn't have branch predictor hints. though i think you mean just taking out code on certain platforms? | ||
| brrt | .tell samcv I mean to create platform-specific #defines, much like we do now, except using #ifdef and friends rather than Configure.pl setting variables | 18:06 | |
| yoleaux | brrt: I'll pass your message to samcv. | ||
| samcv | brrt: i can do that, though what file should i put them in | 18:07 | |
| yoleaux | 18:06Z <brrt> samcv: I mean to create platform-specific #defines, much like we do now, except using #ifdef and friends rather than Configure.pl setting variables | ||
| Redfoxmoon | platform.h or config.h perhaps? :P | 18:09 | |
| brrt | for instance, yes | 18:16 | |
|
18:18
lizmat left
|
|||
| brrt | i mean, it's only a suggestion of course :-) | 18:18 | |
|
18:19
lizmat joined
|
|||
| Redfoxmoon | Seems like good options! | 18:20 | |
|
18:29
brrt left
18:30
colomon joined
18:51
lizmat left
18:56
lizmat joined
19:02
zakharyas joined
19:11
Kaiepi left
19:31
zakharyas left,
lizmat left
19:44
domidumont left
20:08
brrt joined
20:36
lizmat joined
|
|||
| samcv | i think i made MVM_serialization_read_int 18% faster | 21:15 | |
| was looking at perf of perl6 -e '' and that was the top item so tried to optimize it | |||
| jnthn | Wow, nice <3 | 21:17 | |
| A load of them are because of NFAs, but even after we stop storing those in duplicate, NFAs themselves are still a load of ints :) | |||
|
21:21
Kaiepi joined
|
|||
| samcv | got down the percentage of that function in perl6 -e '' from 4.5% to 3.79% | 21:21 | |
| brrt | samcv++ | 21:29 | |
| ohai jnthn | |||
| jnthn | o/ brrt | ||
| How goes? | |||
| brrt | I'm fine, given that it is the end-of-week | ||
| can I get you to look at my PR sometime? | 21:30 | ||
| I kind of want to get it merged sooner rather than later | |||
| jnthn | Yeah. If I find energy over the weekend I will, otherwise can next week | ||
| brrt | (unfortunately, I don't have any benchmark improvmenets to show for it) | ||
| sure :-) | |||
| jnthn | Probably reduced memory a little, if nothing else? | ||
| brrt | code size should be reduced quite considerably, i should think | 21:31 | |
| jnthn | And perhaps callgrind can show a lower cycle count? | ||
| brrt | but it doesn't seem to help much in wallclock | ||
| jnthn | I'll be digging back in to my spesh plugin stuff next week also :) | 21:32 | |
| brrt | anyway, even if it doesn't have any of that, it's still a massive simplicity improvement (even if it is a bit of a risky strategy) | ||
| nice | |||
| jnthn | The last weeks I was somewhat distracted with a certain other project :) | ||
| brrt | you mean comma? | 21:33 | |
| jnthn | Indeed. | ||
| brrt | i kind of want to try it, but i'm not a typical IDE user | ||
| jnthn | Of note, the release engineering. | ||
| Which meant dealing with one Java build tool layered on top of another, weird Windows issues, weird OSX issues, etc. :) | 21:34 | ||
| timotimo | icons, man. how do they ven. | ||
| even* | |||
| jnthn | I know. I can't belive I lost a whole day on a problem that turned out to be "this exe file is considered invalid because the icon file in it has the wrong bit depth2 | 21:35 | |
| (Of course, the error didn't say that. It said "Access denied.") | 21:36 | ||
| brrt | you know what keeps bugging me to *no end* | ||
| everybody who ever thought 'you know what my build tools need? turing complete programming languages' | |||
| also, groovy | |||
| I can't find a *single* redeeming quality to groovy | |||
| nothing whatever | 21:38 | ||
| jnthn | I suspect you either do that or your build system consists of calling out to other turing complete languages for any sufficiently complex build | 21:39 | |
| I didn't think much about groovy, even though I probably wrote it. It looked like Java with some special parse rule for a block after the arguments with a syntax that doesn't make it obviously an argument :) | 21:40 | ||
| hah, yes, of course I wrote it in the last week | |||
| I guess that means it was boring enough I didn't realize I wasn't writing approximately Java ;) | |||
| Anyway, I'll be most glad to return to building features and fixing bugs in Comma next week, rather than dealing with the build system. :-) | 21:42 | ||
| brrt | i feel like groovy is a java that tried to be perlish, but never realized that perls greatest feature was its syntactical affortandces | 21:44 | |
| having said that, i'm having troubles figuring out a case wherein the build itself needed to be turing complete. build tools, compilers, assemblers etc, might be written in turing-complete languages, but that is something completely different | 21:45 | ||
| but maybe i've never seen a complex build up close | |||
| jnthn | It may be a bit of a "worse is better" thing too: in theory declarative is better, but in practice imperative languages are more familiar to more people, and using one for a build system thus makes it feel more like "normal programming". | 21:46 | |
| brrt | hmmm | 21:47 | |
| that's a fair point | |||
| i suppose there are plenty of people who would liked to have had a loop in a makefile | |||
| samcv | i think it should be fine to possible access unaligned memory given most platforms allow that. since all recent archs let you do that | 21:55 | |
| and even if it were slower it's probably cheaper than calling memmem | 21:56 | ||
| err | |||
| memcpy | |||
| brrt | i'm missing some context here | 21:57 | |
| samcv | i'm replacing some of the memcpy is MVM_serialization_read_int with casting a pointer to another type and copying that way | 21:58 | |
| which makes it 15% faster | |||
| brrt | c standards hates you now | 21:59 | |
| :-P | |||
| samcv | yes. well i do it in memmem32 as well though i guess i could check the alignment or something... | ||
| but the speed improvement is worth it unless there is actually a platfom that has an issue with it | |||
| jnthn | Many platforms that aren't x86/x64 have problems with reading non-aligned stuff | 22:04 | |
| We've had quite a few issues from assumptions in that area in the past | 22:05 | ||
| samcv | which platforms? | ||
| jnthn | At least ARM github.com/MoarVM/MoarVM/issues/137 | 22:08 | |
| samcv | The ARMv6 architecture introduced the first hardware support for unaligned accesses. ARM11 and Cortex-A/R processors can deal with unaligned accesses in hardware, removing the need for software routines. | ||
| jnthn | Here's an open PR we didn't merge yet relating to alignment problems: github.com/MoarVM/MoarVM/pull/796 | 22:10 | |
| I'm pretty sure PowerPC needs care too | 22:11 | ||
|
22:19
MasterDuke joined,
brrt left
23:23
Ven`` joined
23:31
Ven`` left
|
|||