Geth docker: 918b44de4f | AntonOks++ | 4 files
Bump to 2025.03 [skip workflow]
 03:08
perlbot Geth: Error: DBD::SQLite::db do failed: database or disk is full at ./plugins/karma_modify.pm line 68.
Geth ecosystem/main: 9b40fec9d8 | (Elizabeth Mattijsen)++ | META.list
Remove PKafka

It will either be maintained, or not. That much is clear		 08:39
perlbot Geth: Error: DBD::SQLite::db do failed: database or disk is full at ./plugins/karma_modify.pm line 68.
tadzik disk cannot contain lizmat++'s karma :) 10:10
perlbot tadzik: Error: DBD::SQLite::db do failed: database or disk is full at ./plugins/karma_modify.pm line 68.
tadzik perlbot: I know :(
perlbot tadzik: Error: DBI connect('dbname=perlbot;host=192.168.32.1','perlbot',...) failed: connection to server at "192.168.32.1", port 5432 failed: Connection refused Is the server running on that host and accepting TCP/IP connections? at ./plugins/factoids.pm line 84.
lizmat perlbot: help
perlbot lizmat: Error: DBI connect('dbname=perlbot;host=192.168.32.1','perlbot',...) failed: connection to server at "192.168.32.1", port 5432 failed: Connection refused Is the server running on that host and accepting TCP/IP connections? at ./plugins/factoids.pm line 84. Provides help text for a specific command. Try 'help echo'. See also the command 'plugins' to list all of the currently loaded plugins.
lizmat so who is running that ? 10:11
apparently perlbot only runs on #raku 10:13
grondilu so I used an enum for chess squares instead of a hash and apparently that decreased the performance :/ 10:51
grondilu almost halved perf 10:51
37s to 55s
I guess I should always check that before committing. 10:54
lizmat intriguing...
could you golf this to a piece of code that we could check ?
grondilu I mean I think that's the issue, again I should have checked before each commit.
lizmat: I don't think I can do that easily.
lizmat also: how do you move from a hash to using enums ? 10:55
perhaps that will give is enough clues :-)
grondilu hang on.
I had a %Ox88 hash that pointed squares as strings such as 'a5', 'e4' etc. to positive integer values. 10:56
so instead I made the following enum:
m: enum Square (([1..8] .reverse X[R~] 'a'..'h') Z=> ((0, 16 ... *) Z[X+] ^8 xx 8).flat); 10:57
camelia ( no output )
grondilu m: enum Square (([1..8] .reverse X[R~] 'a'..'h') Z=> ((0, 16 ... *) Z[X+] ^8 xx 8).flat); say e7
camelia e7
grondilu m: enum Square (([1..8] .reverse X[R~] 'a'..'h') Z=> ((0, 16 ... *) Z[X+] ^8 xx 8).flat); say +e7
camelia 20
grondilu FYI: en.wikipedia.org/wiki/0x88
I suppose I should try to switch back to using %Ox88 and see if I gain the performance back. 10:58
I do have to reverse the enum from times to times though, with something like `Square(e7)`. Maybe that's expensive? 11:00
m: enum Square (([1..8] .reverse X[R~] 'a'..'h') Z=> ((0, 16 ... *) Z[X+] ^8 xx 8).flat); say Square(e6)'
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> *) Z[X+] ^8 xx 8).flat); say Square(e6)<HERE>'
expecting any of:
infix
infix stopper
postfix
statement end
st…
perlbot camelia: Error: DBD::SQLite::db do failed: database or disk is full at ./plugins/karma_modify.pm line 68.
grondilu m: enum Square (([1..8] .reverse X[R~] 'a'..'h') Z=> ((0, 16 ... *) Z[X+] ^8 xx 8).flat); say Square(e6)
camelia e6
grondilu huh?
oh my bad, I meant Square($some-uint-value);
m: enum Square (([1..8] .reverse X[R~] 'a'..'h') Z=> ((0, 16 ... *) Z[X+] ^8 xx 8).flat); say Square(57)
camelia No value '57' found in enum Square
in block <unit> at <tmp> line 1
grondilu m: enum Square (([1..8] .reverse X[R~] 'a'..'h') Z=> ((0, 16 ... *) Z[X+] ^8 xx 8).flat); say Square(3)
camelia d8
lizmat fwiw, it feels like using enums for this is a bit overkill 11:01
grondilu I like being able to use square names literally, though.
besides, this feels right to me. 11:02
lizmat hmmm... I wonder if generating constants rather than enums, would be better performing
grondilu also I like having a "Square" type to use in signatures. 11:03
although performance is important, I don't think it should trump strong typing.
grondilu hum... although now that I think about it, one of the points of 0x88 is to use arithmetic operations for displacements. That won't be easy if I turn squares into an enum. 11:46
librasteve I just made a PR on DBIish github.com/raku-community-modules/...h/pull/243 and would appreciate a 2nd pair of eyes - perhaps someone with DB chops and a Mac who can fix the test failure rather than my brute force idea to just delete the test file mv 43-sqlite-threads.rakutest ../xt? 11:55
grondilu can now confirm that switching back to using %Ox88 brings performance back to 37s 12:01
I suppose I can define the square type as a subset of UInt. 12:02
lizmat grondilu: you want the identifier "a8" to mean 0, right ? 12:04
grondilu lizmat: yes 12:10
lizmat m: my %h = ([1..8] .reverse X[R~] "a".."h") Z=> ((0, 16 ... *) Z[X+] (^8 xx 8).flat).flat; say %h.sort(*.key).map( {"my constant $_.key() = $_.value();" }).join("\n");
camelia my constant a1 = 896;
my constant a2 = 768;
my constant a3 = 640;
my constant a4 = 512;
my constant a5 = 384;
my constant a6 = 256;
my constant a7 = 128;
my constant a8 = 0;
my constant b1 = 913;
my constant b2 = 785;
my constant b…
lizmat would ^^ help ?
Voldenet values are sorta wrong 12:11
a1 should be 70
grondilu so you're thinking a macro would do?
or you mean I would just paste the code? 12:12
lizmat well, then grondilu's algorithm is wrong :-)
what I was thinking of a helper script that produces the constants, and copy-pasting that into your source
grondilu I'm pretty sure my %Ox88 definition was fine.
lizmat: that's very inelegant, tbh
Voldenet m: sub from-sq($sq) { my $o = $sq.ords; $o[0] - 27 + 10 * (49 - $o[1]) }; say ("a".."h" X~ 0..8).map({ $_ => from-sq($_) }) 12:13
camelia (a0 => 80 a1 => 70 a2 => 60 a3 => 50 a4 => 40 a5 => 30 a6 => 20 a7 => 10 a8 => 0 b0 => 81 b1 => 71 b2 => 61 b3 => 51 b4 => 41 b5 => 31 b6 => 21 b7 => 11 b8 => 1 c0 => 82 c1 => 72 c2 => 62 c3 => 52 c4 => 42 c5 => 32 c6 => 22 c7 => 12 c8 => 2 d0 => 83 d…
grondilu I don't just want that code to run and to run fast, I also want it to look nice.
Voldenet m: sub from-sq($sq) { my $o = $sq.ords; $o[0] - 27 + 10 * (49 - $o[1]) }; say ("a".."h" X~ 1..8).map({ $_ => from-sq($_) })
camelia (a1 => 70 a2 => 60 a3 => 50 a4 => 40 a5 => 30 a6 => 20 a7 => 10 a8 => 0 b1 => 71 b2 => 61 b3 => 51 b4 => 41 b5 => 31 b6 => 21 b7 => 11 b8 => 1 c1 => 72 c2 => 62 c3 => 52 c4 => 42 c5 => 32 c6 => 22 c7 => 12 c8 => 2 d1 => 73 d2 => 63 d3 => 53 d4 => 43 d…
Voldenet ^^ a bit simpler approach, idk how fast .ords is, but it might not even need lookups 12:14
lizmat well, one could also create a slang that would allow those identifiers, but I think generating the constants is an elegant way
grondilu m: say ([1..8] .reverse) X[R~] 'a'..'h' Z=> ((0, 16 ... *) Z[X+] ^8 xx 8).flat
camelia ===SORRY!=== Error while compiling <tmp>
Only identical operators may be list associative; since 'X[R~]' and 'Z=>' differ, they are non-associative and you need to clarify with parentheses
at <tmp>:1
------> say ([1..8] .reverse) X[R~] 'a'..'h' …
perlbot camelia: Error: DBD::SQLite::db do failed: database or disk is full at ./plugins/karma_modify.pm line 68.
lizmat fwiw, this approach is used at various places in the core 12:15
grondilu m: say =([1..8] .reverse) X[R~] 'a'..'h') Z=> ((0, 16 ... *) Z[X+] ^8 xx 8).flat
camelia ===SORRY!=== Error while compiling <tmp>
Preceding context expects a term, but found infix = instead.
Did you make a mistake in Pod syntax?
at <tmp>:1
------> say =<HERE>([1..8] .reverse) X[R~] 'a'..'h') Z=> ((
perlbot camelia: Error: DBD::SQLite::db do failed: database or disk is full at ./plugins/karma_modify.pm line 68.
grondilu m: say ([1..8] .reverse) X[R~] 'a'..'h') Z=> ((0, 16 ... *) Z[X+] ^8 xx 8).flat
camelia ===SORRY!=== Error while compiling <tmp>
Unexpected closing bracket
at <tmp>:1
------> say ([1..8] .reverse) X[R~] 'a'..'h'<HERE>) Z=> ((0, 16 ... *) Z[X+] ^8 xx 8).flat
perlbot camelia: Error: DBD::SQLite::db do failed: database or disk is full at ./plugins/karma_modify.pm line 68.
grondilu m: say (([1..8] .reverse) X[R~] 'a'..'h') Z=> ((0, 16 ... *) Z[X+] ^8 xx 8).flat
camelia (a8 => 0 b8 => 1 c8 => 2 d8 => 3 e8 => 4 f8 => 5 g8 => 6 h8 => 7 a7 => 16 b7 => 17 c7 => 18 d7 => 19 e7 => 20 f7 => 21 g7 => 22 h7 => 23 a6 => 32 b6 => 33 c6 => 34 d6 => 35 e6 => 36 f6 => 37 g6 => 38 h6 => 39 a5 => 48 b5 => 49 c5 => 50 d5 => 51 e5 => …
lizmat ok, I'm thinking of bumping perlbot for now
grondilu lizmat: it's ok for core developpers to have different priorities. 12:16
lizmat and for non-core developers as well :-)
grondilu I mean I really don't want to have to copy paste code. 12:17
tell me how to do it with a macro and that'd be a different story.
lizmat well... I don't either, that's why I usually create a helper script that both generates the code *and* paste it in the right place in the source 12:17
so you only need to run the helper script 12:18
Voldenet Shouldn't enums behave exactly like constants (or even define constants)?
lizmat Voldenet: they should, afaik
Voldenet it's very weird that constant-based code would be slower than hash-based one, maybe some specific computation is slower 12:20
grondilu I think it was the calls to &Square before each arithmetic operation. 12:23
because you can do arithmetic operations or enum entries, but you loose the type.
m: my enum color <white black>; say (white + 1) ~~ color # False 12:25
camelia False
grondilu m: my enum color <white black>; say color(white + 1) ~~ color # False
camelia True
grondilu (meant # True above) 12:26
Voldenet m: my $x = 0; my enum color <white black>; sub comp(color $c) { $x += $c }; for 0..1000000 { comp(black) }; say now - BEGIN now; 12:28
camelia 0.096396251
Voldenet m: my $x = 0; my enum color <white black>; sub comp(Int $c) { $x += $c }; for 0..1000000 { comp(1) }; say now - BEGIN now; 12:29
camelia 0.107494914
Voldenet enums don't seem significantly slower
m: my $x = 0; my enum color <white black>; sub comp(Int $c) { $x += $c }; for 0..1000000 { comp(white + 1) }; say now - BEGIN now;
camelia 0.093243744
grondilu I see
I don't know then. 12:30
Voldenet I mean, there's something specific about what gets done with the enum
some operator is slower perhaps
lizmat m: use v6.*; my enum Foo <a1>; my int $a; my $then = nano; $a = $a + a1 for ^10000000; say nano - $then 12:31
camelia 1316328792
lizmat m: use v6.*; my constant a1 = 0; my int $a; my $then = nano; $a = $a + a1 for ^10000000; say nano - $then
camelia 1208219855
lizmat there *is* a difference somehow
grondilu but not a 1 to 2 difference 12:32
again I went from 37s to 55s 12:33
ok not 1 to 2 but almost
lizmat well, if this is not precomped code, then enums take additional CPU on creation, more than just constants 12:34
grondilu but creation is not where I can lose tens of seconds. 12:35
lizmat no, indeed not
grondilu here is my latest commit, the one where I switch back to using %Ox88 : github.com/grondilu/chess/commit/0...ada9ddfce9 12:36
lizmat OOC, why the 3 args loop, why not: for %Ox88<a8> .. %Ox88<h1> -> $i { 12:39
?
Voldenet m: use v6.*; my enum Foo <a1>; my int $a; my $then = nano; my $a1 = "a1"; $a = $a + Foo::{$a1} for ^10000000; say nano - $then 12:40
camelia 1665014047
Voldenet now that's significantly slower
m: use v6.*; my %foo = 'a1', 1; my int $a; my $then = nano; my $a1 = "a1"; $a = $a + %foo{$a1} for ^10000000; say nano - $then 12:43
camelia 2386414908
Voldenet nevermind, hashes seem a lot slower
m: use v6.*; constant %foo = 'a1', 1; my int $a; my $then = nano; my $a1 = "a1"; $a = $a + %foo{$a1} for ^10000000; say nano - $then 12:44
camelia 1666772312
grondilu didn't your examples show that enums are faster?
Voldenet indeed, not by a lot, but they seem faster 12:45
the last example shows that parsing enums uses constant hash
the speed is about the same 12:46
grondilu I see
well I defined %Ox88 as a constant hash, precisely
Voldenet So now I'm speculating that it's not about operators, which are as fast, but maybe about types returned 12:48
m: my constant %foo = "a1", 1; say %foo{$_}.WHAT for "a1","a2" 12:49
camelia (Int)
Nil
Voldenet m: my enum Foo <a1>, 1; say Foo::{$_}.WHAT for "a1","a2"
camelia WARNINGS for <tmp>:
(Foo)
(Any)
Useless use of constant integer 1 in sink context (lines 1, 1)
Voldenet m: my enum Foo <a1>; say Foo::{$_}.WHAT for "a1","a2"
camelia (Foo)
(Any)
Voldenet maybe Int gets optimized somewhat and Foo doesn't 12:50
grondilu m: use v6.*; my enum Foo <a1>; my int $a; my $then = nano; $a += a1 for ^10000000; say nano - $then 12:52
camelia 1195904188
grondilu m: use v6.*; my %Ox88 = a1 => 0; my int $a; my $then = nano; $a += %Ox88{a1} for ^10000000; say nano - $then 12:53
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared routine:
a1 used at line 1
grondilu m: use v6.*; my %Ox88 = a1 => 0; my int $a; my $then = nano; $a += %Ox88<a1> for ^10000000; say nano - $then
camelia 1984391066
grondilu m: use v6.*; constant %Ox88 = a1 => 0; my int $a; my $then = nano; $a += %Ox88<a1> for ^10000000; say nano - $then
camelia 1697558205
grondilu well, that's no help 12:54
Voldenet m: use v6.*; const %Ox88 = a1 => 0; my int $a; my $then = nano; $a += %Ox88<a1> for ^10000000; say nano - $then 13:01
camelia ===SORRY!=== Error while compiling <tmp>
Variable '%Ox88' is not declared. Perhaps you forgot a 'sub' if this
was intended to be part of a signature?
at <tmp>:1
------> use v6.*; const <HERE>%Ox88 = a1 => 0; my int $a; my $then = n
Voldenet m: use v6.*; constant %Ox88 = a1 => 0; my int $a; my $then = nano; $a += %Ox88<a1> for ^10000000; say nano - $then
camelia 1348314157
Voldenet …wait a second, those microbenchmarks may be not very fair 13:02
m: use v6.*; constant %Ox88 = a1 => 0; my int $a; my $then = nano; $a += %Ox88<a1> for ^10000000; say nano - $then
camelia 1492261614
Voldenet ah, there is one operator I didn't check for 13:05
use v6.*; constant %Ox88 = a1 => 0; my int $a; my $then = nano; $a += (%Ox88<a1> == %Ox88<a1>) for ^10000000; say nano - $then 13:07
evalable6 3773525390
Voldenet use v6.*; my enum Foo <a1>; my int $a; my $then = nano; my $x = "a1"; $a += (Foo::{$x} == Foo{$x}) for ^10000000; say nano - $then
grondilu talking about operators, maybe bitwise operators are the issue. The move generation algorithm does use them. 13:08
Voldenet m: use v6.*; my enum Foo <a1>; my int $a; my $then = nano; my $x = "a1"; $a += (Foo::{$x} == Foo::{$x}) for ^10000000; say nano - $then
camelia 2775934497
grondilu m: use v6.*; constant %Ox88 = a1 => 0; my int $a; my $then = nano; $a +&= %Ox88<a1> for ^10000000; say nano - $then
camelia 1730592311
grondilu m: use v6.*; my enum Foo <a1>; my int $a; my $then = nano; $a +&= a1 for ^10000000; say nano - $then 13:09
camelia 1519790446
grondilu doesn't look like it
Voldenet there's one specific thing about current Enum implementation that adds === operator
github.com/rakudo/rakudo/blob/main...kumod#L136
It could be relevant
grondilu I suppose I could create a version with both the enum and %Ox88 would be available, and I'll change what I used only one change at a time until I figure where the performance loss shows up. 13:17
grondilu realizes that wouldn't be as easy as he thought initially 13:34

Powered by Cro and the Raku® Programming Language.

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

Thank you!