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
|