Parrot 4.7.0 "Hispaniolan" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 4 September 2012.
00:15 benabik joined 00:21 MikeFair joined 00:34 kid51 joined 02:06 nopaste joined 02:34 mvorl left 03:45 benabik joined 04:09 benabik joined 05:08 alvis_ joined 05:43 cosimo joined 05:45 NotFound_b joined 05:48 arnsholt_ joined, Maddingu1 joined 05:53 ttbot joined 07:22 woosley joined 08:11 lucian joined 08:20 Psyche^ joined 08:48 mdupont joined 12:21 mtk joined 12:24 benabik joined 12:33 JimmyZ joined 13:20 bluescreen joined 13:59 benabik joined
benabik ~~ 14:14
14:14 PacoAir joined 14:58 benabik_ joined 15:00 mvorl joined 15:27 dmalcolm joined
dalek rrot/native_pbc2: e697588 | rurban++ | t/native_pbc/number_4_4_be.pbc:
native_pbc/number_4_4_be.pbc added
 15:58
rrot/native_pbc2: 5f4222d | rurban++ | config/gen/config_pm/myconfig.in:
display FLOATTYPE_? in myconfig
 16:34
16:55 alvis joined 17:03 tuxit joined 17:24 patspam joined 17:33 mvorl joined 17:45 contingencyplan joined, aloha joined 18:06 benabik_ joined 18:08 benabik__ joined 18:12 sivoais joined 18:17 zby_home joined 18:24 zby_home joined
dalek kudo/nom: a19ce8b | jnthn++ | src/core/LoL.pm:
Make infix:<X> a bit cheaper. This doesn't really deal with what seems to be an algorithmic problem, but it is an easy and noticable win.
 18:28
18:37 zby_home joined
benabik rurban++ pointed out vmkit on #perl6. Pondering it as a version of M0. 19:05
1) LLVM does not appear to natively support continuations. 19:06
2) VMKit _looks_ to be designed to support stack-based languages, but I see nothing that would prevent doing registers. 19:07
It would allow us to use LLVM as our ops language, which means they could be written in, basically in-VM C. 19:08
llvm-lua is talking about doing continuations via LLVM 19:11
sorear the interesting question then becomes, do you try to use the native stack, or do you set up a special parrot stack? 19:12
benabik Parrot doesn't use the stack.
sorear a custom stack with a register allocated for the top works quite well for ghc 19:13
benabik Right.
rurban That's up to LLVM. Native stack of course
benabik It's not entirely up to LLVM.
sorear Don't say "of course" so quickly.
rurban but with fastcall most of the the args are in registers.
sorear There are a lot of restrictions on the use of the native stack
rurban with i386 on the stack.
which? 19:14
stacksize 8MB? faster?
sorear no tailcalls in half the cases on unix
benabik If we generate code that always .tailcalls and mostly store variables in GC-managed continuations, that's very different than what LLVM would do by default.
sorear large stacks since no good resize support
benabik code.google.com/p/llvm-lua/wiki/St...TFunctions
rurban true
sorear no easy coroutines on Windows 19:15
makes on-stack replacement and precise stack marking a bit harder
Coke if parrot can be made to use llvm - what's left of parrot? 19:16
benabik Ops, interop, object model.
LLVM is the base on which Parrot ops are written.
rurban Coke: pbc only
I don't know about the pmc's 19:17
But parrot will always be the default basis for nqp and rakudo. At least to bootstrap it.
But if parrot's calling convention is way too slow, why bother. 19:18
benabik Coke: llvm is a compiler tool, not a VM. vmkit adds memory management and JIT core. Parrot would add objects, high-level ops, etc.
rurban And I don't think lorito is a practical way.
benabik Parrot is far more than a calling convention. It's a pain point right now, but it can be fixed. 19:19
vmkit seems to be completely agnostic to execution style and variable storage. stack, register, continuation, etc 19:20
atrodo How would LLVM and vmkit imrpvoe interop more than m0/lorito? 19:21
or even compared to parrot today
benabik It could improve speed (JIT vs interp), free developer time from GC and Threads... 19:22
(We'd still need the conceptual models that nine++ developed, but implementation is much freer.)
Interop is still our problem. :-D 19:23
Although building on LLVM might ease Parrot<->C jumps.
atrodo So is parrot's goal speed or interop or rakudo?
rurban rakudo which is speed
atrodo Put another way, what exactly is parrot goal at this point?
rurban not die 19:24
Coke rakudo has to be our main priority, I think.
rurban if it does not get a performance boost rakudo is forced to use better vm's
See nqp QAST
benabik Parrot's goal is to be a wonderland of interop and ease of development for dynamic languages. 19:25
More practical goals include speed and learning from Rakudo's improvements.
rurban yes, if rakudo is gone, parrot can try to persuade the others to come back.
atrodo If I was rakudo, I'd be asking why it even needs parrot at all 19:26
benabik I'm excited by Parrot as an educational and development environment.
While I'm interested in Rakudo, it's not why I care about Parrot.
rurban They are asking themselves this constantly.
benabik sighs.
moritz atrodo: hysterical raisins 19:27
atrodo benabik: I am too. I think parrot has huge potential, but if it only chases rakudo, what future does it really have?
benabik Can I not ponder possibilities about how to implement a register and continuation based VM for dynamic languages without dredging up this crud?
moritz though parrot does have some very helpful bits that other VMs don't offer 19:28
benabik really hates this recurring "why does Rakudo need Parrot" business.
Coke benabik: Sure, but at some point, don't we have to ask "if we're going to write code for parrot, why are we doing it" ?
moritz like the ability to write your own multi dispatch in C
atrodo benabik: Sorry, I'm not aiming at you, I'm also wondering outloud
rurban You can do, but we need to focus on helping our main customer
benabik Parrot is about providing tools. Most VMs come with built-in object models, built-in ideas about exceptions and control flow. 19:29
Coke so, backing up: what are we arguing about?
rurban Because when rakudo goes away parrot is dead, rakudo only needs it for bootstrapping nqp.
benabik rurban: When Rakudo goes away I co-opt Parrot as my personal thesis research playground. :-D
Coke benabik: you can do that today with a fork.
rurban rakudo might be renamed if it switches to another vm. 19:30
benabik Coke: Like, say, a vmkit based fork?
Coke as someone who's tried to target parrot for a while, I've given up on targetting parrot directly. I'm targetting nqp these days.
rurban I would do so, to keep a straight face.
The vmkit based fork was my idea :)
Coke given that most of rakudo is written in perl6 and not parrot, I doubt that'll happen. 19:31
moritz rurban: now write a patent application for it :-)
benabik rurban: vmkit based NQP... I wanted to talk more generally about it for other languages.
I've been pondering what I'd like to see Parrot be, to some extent, and vmkit is a lovely match for some of it.
Assuming I can get efficient continuations out of it. 19:32
Parrot is amazingly pluggable, but much of its extensibility comes with large costs. 19:36
Our ops generation is painful, our calling conventions are too slow, our object model is clunky. 19:37
The way we manage our namespaces makes my head hurt.
rurban Our ops.pmc's are quite nice imho.
benabik In concept, yes.
But we suffer from huge code bloat in opsgen. 19:38
rurban yes
We have no good optimizer
benabik It's just code duplication. We expect ops to handle the difference between registers and constants and piles of other things instead of having a nice generic interface to these things. 19:39
dalek rrot/native_pbc2: ecd4ef1 | rurban++ | config/ (2 files):
use PARROT_FLOATVAL_DIG for rounding, set i_quadmath
 19:42
rrot/native_pbc2: f98d38b | rurban++ | / (4 files):
[GH #807] Refactor native_pbc endianness, bswap64. Add header argument to converters

Convert endianness upfront does not work. Some converters work on native floats, to do compiler casts. They need to know the packfile byteorder. Other bitfiddling converters work only on little-endian, so we also need to know the packfile byteorder, and they also need to convert endianness back to to the target format.
Refactor bswap64, as it only works with 64bit registers. Tested with HAS_INT64. So there are two bswap64 API's, one for fast native conversion via a register and one with two unsigned char * args, which might point to the same buffer, for easier in-place conversion.
Added dummy ROUND_NUM_TO macro, which needs to round a long number down to the given precision (when converting upwards). Can be done with sprintf, but need to find a better way.
Simplify converter casts with unions.
Replace SWAB_12 with SWAB_10. TODO: Need to check the last two bytes.
benabik The lack of optimization is a problem across the board to some extent, which is why vmkit making it easy to reuse all the LLVM optimizers is nice.
rurban yes, that was one of my ideas, also to use a better GC.
benabik Yeah, the mention of Immix in vmkit really caught my eye. 19:44
moritz is GC still a bottleneck?
rurban A stop-the-world gc always has some marketing issues.
moritz in parrot, that is
benabik It's probably not our major bottleneck, but being able to get better GC without additional work is a plus in my book.
rurban it's tricolor with generations now, but still I'd like a batter concept at all, sooner or later 19:45
better
benabik Better meaning more featured. A global stop-the-world GC is very bad with threads.
rurban Better copying then mark-sweep
moritz benabik: but isn't it stop-the-thread in the threads branch? 19:46
rurban Our threads do fine with the gc now and proxies, that's fine. No measurable speed loss.
stop the threads and stop the world. and best: it does not check out-of-memory. 19:47
benabik moritz: I'll have to admit I don't know. :-/ 19:49
Really GC from vmkit is nice for me because I don't want to maintain a GC. :-D And attracting developers who do is difficult.
Coke Anyway, I'm happy to see people discussing where to spend tuits, thanks for keeping parrot alive.
benabik: that is an excellllllent point which I think has not been enough embraced over parrot's lifetime. We should definitely not be reinventing wheels when perfectly round ones are available. 19:50
rurban The vmkit is really mmtk from Jikes
benabik Coke: But have they tried octagonal? I think we have some of those around in the codebase.
benabik kids. 19:51
rurban MMTk
Coke ooh, jikes. I remember when that was first available. 19:52
rurban The vmkit GC is really MMtk from Jikes (sigh)
benabik Hey, if I can get a GC written by IBM research, I'll take it. :-D 19:53
rurban But it's written in java! 19:54
benabik I rather doubt they wrote the GC in Java, although I could be wrong. 19:55
rurban jikesrvm.svn.sourceforge.net/viewvc.../jikesrvm/
That's why I am a little bit nervous. 19:56
benabik Well, then, I'm wrong.
I don't see the memory managers in there, just the Java interface. 19:57
It looks like the MMTk bits in vmkit are in C++ 20:00
llvm.org/viewvc/llvm-project/vmkit/trunk/mmtk/
rurban llvm.org/viewvc/llvm-project/vmkit/...mmtk/plan/ 20:01
benabik So vmkit requires a running JVM?
This feels wrong.
rurban j3 is basically a jvm.
benabik c3 isn't.
Or was it N3?
rurban forgot
benabik N3 for Net, I think. 20:02
We'd lose a lot of portability, apparently. LLVM's JIT is x86 only. 20:03
Coke no worse than our previous JIT. 20:04
benabik Yes, but I don't see a non-JIT mode for vmkit.
Coke odd.
rurban There is a AOT compiler
benabik And they apparently use Java-written GCs, compiled to LLVM via their JVM.
That's... odd. 20:05
rurban yep
we could write a GC in nqp
Coke +1 20:06
Or winxed, which is filling the slot that I thought scheme might at some point.
rurban Anyway, first I'll have to fix my numbers, then threads, then study vmkit. 20:08
dalek rrot/native_pbc2: f9561fc | rurban++ | t/native_pbc/number_8_4_le.pbc:
add t/native_pbc/number_8_4_le.pbc (it crashes on different ptrsizes)
 20:26
rrot/native_pbc2: 1716ee5 | rurban++ | / (2 files):
Improve number.t output (print desc)

Update testmatrix.		 20:37
21:27 benabik joined
dalek p: c810874 | jnthn++ | src/QRegex/P5Regex/Grammar.nqp:
Toss P6Regex leftover.
 21:28
p: 37cb811 | jnthn++ | src/QRegex/P5Regex/Grammar.nqp:
Parse non-alphanumerics without a meaning as literal characters to match.
p: f1027a4 | jnthn++ | t/p5regex/rx_charclass:
Test for /a]/.
p: 1a194af | jnthn++ | / (2 files):
Fix \\B, plus a test.
 21:40
kudo/nom: ba04210 | jnthn++ | tools/build/NQP_REVISION:
Get latest NQP for P5Regex improvements.
 21:48
kudo/nom: d624613 | jnthn++ | t/spectest.data:
Run S05-modifier/perl5_1.t.
23:32 benabik joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!