| 21 Oct 2024 |
| coleman |
does zef have a concept of "meta-libraries" such that we can rally around a collection of versions installable by zef |
19:50 |
|
|
and then from there implement lower-level optimizations |
|
|
| [Coke] |
ab5tract: you know Rakudo has builtin JSON support, yes? |
19:52 |
|
| ab5tract |
you mean the one that's been deprecated for over half a decade? |
19:53 |
|
|
I'm talking about something that can operate at native speeds |
|
|
| [Coke] |
sorry, deprecated? |
19:54 |
|
|
but sure, if the goal is "faster", excellent. just trying to be clear. |
19:55 |
|
|
(deprecated) ah, yes, the REPL doesn't complain about that until you exit. ;) |
19:56 |
|
| ab5tract |
the idea is that JSON::Fast is as fast as NQP gets |
|
|
|
Java has faster deserializers at hand |
|
|
|
so does C |
|
|
|
we don't expose VM hashes to the HLL |
|
|
|
this is something that caused JSON::SIMD to be unable to achieve much of a performance differential |
19:57 |
|
|
leaving JSON support to an after-market module in 2024 is ... a choice |
20:01 |
|
| jdv |
perl does, no? |
20:02 |
|
| ugexe |
or java :) |
20:05 |
|
|
but Go got the standard library right |
|
|
| ab5tract |
yeah, neither of those are good examples |
|
|
|
perl got bitten by too many internalized modules (which I understand) |
20:06 |
|
|
Java is dumbfoundingly useless by itself |
|
|
|
it still ships with a CSV parser, iirc |
|
|
|
(perl) |
|
|
|
which is a rough equivalent of JSON, era to era |
20:07 |
|
|
Anyway, the whole utility of the idea is that nothing in third-party space can fill a VM hash.. therefore leaving it to a third-party module necessarily leaves performance optimization opportunities on the table |
20:09 |
|
|
this isn't the case for Perl, or Java |
|
|
| ugexe |
yeah, although it sort of gets into the "well what about the jvm backend" |
20:13 |
|
|
although i guess jvm could just use some module like we already do for other stuff |
20:14 |
|
|
some java module |
|
|
|
it would complicate things a bit though since the "on jvm do this on moar do that" would presumably need to be applied to a *module* i.e. something in lib/ and not actually in the core |
20:15 |
|
|
anyways im sure that problem can be solved so its probably not worth thinking too hard about |
20:16 |
|
| jdv |
isnt that just doing xs all over again? |
20:25 |
|
| ab5tract |
in JVM land I would introduce Kotlin and its builtin serialization |
20:26 |
|
|
jdv: no, it's really not. it's recognizing that some things deserve to be closer to the VM than NativeCall allows, and those things likewise deserve being in core |
20:27 |
|
|
ugexe: I'm not sure I understand, exactly. Any VM would ultimately expose JSON serialization as nqp routines. So the core `JSON` library would look the same from the perspective of the HLL |
20:28 |
|
| |Tux| |
Rakudo v2024.09-138-gd964ec93a (v6.d) on MoarVM 2024.09-10-g939e64dc8
| csv-ip5xs | 0.261 | - | 0.262 |
| csv-ip5xs-20 | 1.095 | - | 1.099 |
| csv-parser | 1.491 | - | 1.519 |
| csv-test-xs-20 | 0.142 | - | 0.144 |
| test | 1.859 | - | 1.877 |
| test-t | 0.396 | - | 0.403 |
| test-t --race | 0.269 | - | 0.273 |
| test-t-20 | 4.723 | - | 4.813 |
| test-t-20 --race | 1.163 | - | 1.179 |
|
21:48 |
|
|
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log |
|
|
| 22 Oct 2024 |
| releasable6 |
Next release in ≈2 days and ≈11 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft |
07:00 |
|
|
lizmat hopes jdv's Blin run worked out ok |
09:31 |
|
| jdv |
lizmat: i got a run in but i haven't curated it. i'll do that tonight but if you're bored here's the raw output: gist.github.com/jdv/eed6eaef8eb874...df7e3258d7 |
15:26 |
|
|
thanks for that fix |
|
|
| [Coke] |
why is the menu:simple run complaining about perl6lib - is that coming from your blin? |
15:52 |
|
|
ah, likely |
16:04 |
|
| lizmat |
jdv: looking at them now, as they all seem to be caused by commits I did |
17:24 |
|
|
jdv: going afk, the Dan issue is a bit more tricky to decide what to fix |
18:53 |
|