|
00:11
silug left
|
|||
| disbot6 | <antononcube> Interesting! | 00:12 | |
|
00:34
silug joined
01:06
arkiuat joined
|
|||
| arkiuat | speaking of illegitimate uses of class Instant's epoch, I just realized there's an easy way to get a good approximation to Terrestrial Time (what they used to call Ephemeris Time) from raku | 01:11 | |
| m: say DateTime.new(Instant.from-posix(now.Rat + 32.184)).truncated-to('second') | |||
| camelia | 2025-12-12T01:12:36Z | ||
| arkiuat | it also makes illegitimate use of the .from-posix method, basically pressing it into service as a date formatter for a non-posix count of seconds | 01:12 | |
| I used the 'now' term there, but this totally wouldn't work if you tried it on dates before 1970 | |||
|
01:23
DarthGandalf left
02:07
eseyman left
02:09
eseyman joined
02:17
sibl joined
02:47
hulk joined,
kylese left
02:54
sibl left,
sibl joined
03:09
DarthGandalf joined
03:15
hulk left,
kylese joined
03:40
sibl left
04:15
arkiuat left
04:19
Aedil joined
04:27
arkiuat joined
04:31
arkiuat left
04:52
arkiuat joined
05:02
arkiuat left
05:03
arkiuat joined
05:51
Aedil left
06:25
Pixi left
06:27
Pixi joined
06:40
justache left,
justache joined
07:30
arkiuat left
07:35
arkiuat joined
07:42
abraxxa joined
07:46
swaggboi left,
arkiuat left
07:54
arkiuat joined
07:58
arkiuat left
08:00
lue joined
08:02
ShimmerFairy left,
Sgeo left
|
|||
| disbot6 | <librasteve> Voldenet: a coupla days ago, I said: actually the start server, check page is opne I would put in xt - because eg localhost may not be configured, or firewall posrt may be closed, etc ... please take a look at the bottom of this cro issue to see the kind of thing that can easily happen - even with an experienced user github.com/croservices/cro/issues/...3644270894 | 08:06 | |
|
08:08
lue is now known as ShimmerFairy
08:16
abraxxa left
08:26
arkiuat joined
08:29
sibl joined
08:31
silug1 joined,
arkiuat left
08:32
silug left,
silug1 is now known as silug
08:33
sibl left
|
|||
| Voldenet | librasteve: Yes, that's why I said 127.1 – localhost is totally not guaranteed to work | 08:54 | |
| > github.com/niklas-heer/speed-compa...ibniz.raku | 08:55 | ||
| disbot6 | <librasteve> fair enough 127.1 much better than localhost, I do not know enough about IP level loopbacks and security controls to use facts to persuade you of my case, so I guess we wikl have to diagree agreeably on this | 08:58 | |
| Voldenet | using methodology of this test can lead you to believe that having gigantic binary with lookups is the best…, since there's nothing to compute then ;) | ||
| I don't know too much about low-levels of it either, just that I've never had a case where 127.1 didn't work* (* actually IIS refuses to authenticate localhost users using windows authentication, but that's deliberate). | 09:00 | ||
| librasteve_ | i tried with hyper (just to see if it was faster) — sadly not with this version www.irccloud.com/pastebin/29FSK5T5 | ||
| disbot6 | <librasteve> of course, the fastest native Raku solution is ... | ||
|
09:01
arkiuat joined
|
|||
| disbot6 | <librasteve> m: say π | 09:01 | |
| librasteve_ | m: say π | ||
| camelia | 3.141592653589793 | ||
|
09:03
silug left
|
|||
| Voldenet | though tbh. raku is not very great for computations needing speed, that's why nativecall is so easy to use | 09:03 | |
| people using react have proven that people actually don't care about speed at all | 09:04 | ||
| react is the slowest and it keeps getting slower (react hooks are slower than earlier components, for instance) | |||
| and people not using C have proven the same thing | 09:05 | ||
|
09:06
arkiuat left,
silug joined
|
|||
| disbot6 | <librasteve> I think it is a central theme of script languages like Raku that speed of writing, reading and understanding code for maintenance is more valuable than speed of execution - in fact the whole idea of Raku is that it is high level glue to stitch together standard and custom native (C/C++) libraries [and for Raku read Python, Ruby, PHP and so on ... except that these have had 1000s person years applied to compiler optimisation | 09:09 | |
| and Raku has yet to climb that ramp | |||
| <librasteve> not least because computers (Mac M5 anyone) have more and more power that mostly sits there idle | 09:10 | ||
| <librasteve> there are lies, damned lies and benchmarks | 09:11 | ||
| jast | that feels like a really weak argument, because the point of having that power isn't to max it out and consume as much electricity as possible :) | 09:13 | |
| but yeah, if I think performance, I don't think scripting languages | |||
| Voldenet | in fact, python isn't fit for this, so people kinda use it as code glue for setting up C++ lib | ||
| people don't aim for consuming as much electricity though, they just don't optimize things that are fast enough | 09:16 | ||
|
09:19
silug left
09:20
sibl joined
|
|||
| librasteve_ | jast: think about the arc of computing - from ASM to C to Java to Python to Raku - each step has reduced execution speed in exchange for more powerful abstractions … imo, the recent trend for safe and fast languages (Rust) is an oddity … coding in Rust (for me at least) is like going to the dentist | 09:22 | |
| jast | I like Rust | ||
| but I like Raku too | 09:23 | ||
| and I'm not arguing with the point you're making, I just think saying "computers have so much power anyway" is the right argument to make in favour of scripting languages. Abstractions and expressiveness of code... that's more like it | 09:24 | ||
| librasteve_ | OK - it’s a personal thing - I cant remember the number of times I typed unsafe - but I think it is fair to say that Rust and Raku are quite different tools for quite different tasks | ||
| jast | absolutely | ||
| I happen to be quite interested in the kinds of things that Rust is a great fit for | |||
| but obviously that's not all I do (let alone everyone else) | 09:25 | ||
| librasteve_ | well I tried to write an OS in Raku and ended with with App::Crag | ||
| Voldenet | I actually think that code directly compiling into machine code is not that great, because optimization has to be done on real data in realtime | 09:26 | |
| librasteve_ | yeah - iirc jit is quite limited in current raku until we can get to AST… right? | 09:27 | |
|
09:27
silug joined,
sibl left
09:28
arkiuat joined
|
|||
| Voldenet | I remember checking and it'd be possible to dump and load mvm bytecode directly | 09:32 | |
| so what get optimized is probably mvm bytecode | |||
|
09:33
arkiuat left
|
|||
| Voldenet | AST gets kind of optimized too though | 09:35 | |
|
09:38
melezhik_ joined
|
|||
| Voldenet | I'm actually wondering if various variants of raku wouldn't be faster than moarvm in that specific benchmark | 09:40 | |
|
09:53
tgt joined
10:02
arkiuat joined
10:07
arkiuat left
10:09
melezhik_ left,
melezhik_ joined
10:19
melezhik_ left
10:25
tgt left
10:29
arkiuat joined
10:34
arkiuat left
10:39
lichtkind joined
10:48
arkiuat joined
10:52
arkiuat left
10:54
Aedil joined
11:04
arkiuat joined
11:08
arkiuat left
11:13
arkiuat joined
11:18
arkiuat left
11:29
melezhik_ joined
11:39
tgt joined
11:45
abraxxa joined
11:47
arkiuat joined
11:51
abraxxa left,
abraxxa1 joined,
arkiuat left
11:54
tgt left
11:59
melezhik_ left,
melezhik_ joined
12:05
melezhik_ left,
melezhik_ joined
12:10
abraxxa1 left
12:14
arkiuat joined
12:17
melezhik_ left,
melezhik_ joined
12:19
arkiuat left
12:23
melezhik_ left,
melezhik_ joined
12:42
melezhik_ left
12:43
melezhik_ joined
12:46
arkiuat joined
12:50
melezhik_ left,
melezhik_ joined
12:51
arkiuat left
13:02
melezhik_ left,
melezhik_ joined
13:09
melezhik_ left,
melezhik_ joined
13:15
melezhik_ left,
melezhik_ joined,
arkiuat joined
13:19
librasteve_ left
13:20
arkiuat left
13:27
melezhik_ left,
melezhik_ joined
13:38
melezhik_ left,
melezhik_ joined
13:48
arkiuat joined
13:51
melezhik_ left
13:52
melezhik_ joined
13:53
arkiuat left
13:57
melezhik_ left,
melezhik_ joined
14:07
melezhik_ left
14:08
melezhik_ joined
14:12
melezhik_ left
14:13
melezhik_ joined
14:16
arkiuat joined
14:21
arkiuat left
14:26
melezhik_ left,
melezhik_ joined
14:33
phogg left
14:35
lichtkind left,
arkiuat joined
14:37
melezhik_ left,
melezhik_ joined
|
|||
| disbot6 | <antononcube> @Voldenet "though tbh. raku is not very great for computations needing speed, that's why nativecall is so easy to use" -- this can be said for Python and R. | 14:39 | |
| lizmat | korvo: github.com/rakudo/rakudo/pull/6040 | ||
|
14:42
arkiuat left
14:44
melezhik_ left,
melezhik_ joined
14:49
melezhik_ left,
melezhik_ joined
14:50
Sgeo joined
14:54
arkiuat joined
14:57
melezhik_ left
14:58
melezhik joined
14:59
arkiuat left
15:00
arkiuat joined
15:05
arkiuat left
15:07
halloy3613 joined
|
|||
| halloy3613 | librasteve: I'm really sorry about this but I can't make the publishing deadline | 15:08 | |
|
15:08
halloy3613 left
|
|||
| ab5tract | sorry, the above was from me ^^ | 15:08 | |
| any advent writer out there able to switch dates with me? | 15:14 | ||
| patrickb | when is your post? | 15:18 | |
| ab5tract | tomorrow :( | 15:21 | |
| Alternatively, I could write it tomorrow and have it published a bit later than normal. | 15:22 | ||
| But today something came up and I just won't have the time | |||
|
15:23
phogg joined
|
|||
| patrickb | Ah ... Maybe I could whip something up very quickly. | 15:24 | |
| ab5tract | You'd be doing me a huge favor 💝 | 15:29 | |
|
15:31
arkiuat joined
15:36
arkiuat left
|
|||
| disbot6 | <antononcube> I already have three Raku advent posts published, otherwise, I would have volunteered. (My fourth is "just in case" if there are not enough posters.) | 15:42 | |
|
15:47
arkiuat joined
15:52
arkiuat left
15:54
arkiuat joined
15:59
arkiuat left
16:01
arkiuat joined
16:06
arkiuat left
16:16
MoC joined
16:26
arkiuat joined
|
|||
| Voldenet | antononcube: you're perfectly right, though python really looks like asm more than anything else to me | 16:29 | |
| it's just so, so extremely verbose | |||
| disbot6 | <antononcube> I was recently comparing large(r) sparse multiplication timings in Python and Raku. | 16:32 | |
|
16:34
arkiuat left
|
|||
| disbot6 | <antononcube> The core C implementations (i.e. NativeCall) perform the same -- same timings. Since the packages I compare provided matrices with named rows and columns, this makes Raku 10 times slower. I.e. the management of row- and column name-to-index hashmaps in Raku is at least 10 times slower than Python's. | 16:36 | |
| Voldenet | …meaning that dicts in python are faster than hashes in raku? | 16:37 | |
|
16:38
human-blip left
|
|||
| korvo | Voldenet: FWIW speed is generally a structural property, rather than something that comes from choosing a particular way of computing. I looked at how difficult it would be to add NQP backends for RPython or GNU Lightning; I also considered how difficult a QBE backend would be. Difficult enough to not classify as a weekend project. | 16:38 | |
| disbot6 | <antononcube> I am not sure about hashmap retrieval. But the hashmap creation (and destruction, maybe) is 10 times slower in Raku. | 16:39 | |
| korvo | lizmat: Nice! That's certainly a more holistic approach than fixing just the one benchmark. | ||
|
16:40
human-blip joined
|
|||
| disbot6 | <antononcube> @Voldenet I kind of have hard time profiling that code. I have to re-learn doing Raku profiling (using sqlite.) | 16:40 | |
| Voldenet | huh, that's intriguing, did you use the nqp hash directly? | 16:46 | |
|
16:46
arkiuat joined
|
|||
| disbot6 | <antononcube> No. I haven't thought about that way. | 16:46 | |
| Voldenet | m: use nqp; my \h = nqp::hash(); nqp::bindkey(h, "foo", 42); nqp::atkey(h, "foo").say # this | 16:47 | |
| camelia | 42 | ||
| Voldenet | I wonder how much of it came from the syntax overhead and which was hash impl difference | ||
| disbot6 | <antononcube> Yeah, I figured that my there are some more fundamental questions like these to be answered. | 16:50 | |
|
16:51
arkiuat left
|
|||
| Voldenet | I generally agree that "speed is generally a structural property" but particular requirements will affect what you'd prioritize | 17:01 | |
|
17:01
human-blip left
|
|||
| Voldenet | You'd think that monomorphized generics are always faster and double dereference is always slow but in practice for some code (a lot of monomorphized variants) dynamic double dereference can be faster | 17:02 | |
| just as an example | 17:03 | ||
|
17:03
human-blip joined
|
|||
| Voldenet | and way of computing also affects size of code in bytes, so they're inseparable for most practical applications | 17:05 | |
|
17:05
arkiuat joined
17:07
lichtkind joined
|
|||
| korvo | Voldenet: I agree with all of that. I suppose I was responding specifically to your thoughts about whether Raku or MoarVM would be a better place to look for optimizations. A variant of Raku which builds upon something like QBE would presumably do very well on this particular benchmark, at the expense of not being able to warm up any allocation-heavy code. | 17:08 | |
| Voldenet | Yes, I remember niecza (.net backend) that was abandoned just before ryujit was released | 17:11 | |
| so I was looking at implementing .net backend and while it doesn't sound extremely hard, it's actually massive thing to work on | 17:12 | ||
| Though I think there's not a single place to look for in optimizations - for instance it matters whether you do `for $ref<> …` or `for @($ref)` | 17:16 | ||
| but if you're only iterating over the list it doesn't have to be cloned, so it can be safely optimized to decontainerize by default | 17:17 | ||
| in fact depending on what you do with it, it could be even differently iterated by moarvm because it's a list | 17:19 | ||
| and not some generative iterator | |||
| (if it's normal reified list of course) | |||
| korvo | Sure. But also, when using something like RPython or GNU Lightning, sometimes the idiomatic approach is fast. I've had RPython code where I test whether the JIT is enabled so that I *skip* caches on JIT; it's faster to just do a JIT'd access than to ask the JIT to writeback to cache. | 17:20 | |
| disbot6 | <antononcube> @Voldenet Looking at your example -- what is the fastest way to copy or clone one large hashmap into another? | 17:21 | |
| korvo | (I hear Truffle can do this sort of thing too, but friends don't let friends use Oracle products.) | ||
| Voldenet | antononcube: nqp::clone I suppose | 17:23 | |
| m: use nqp; my \h = nqp::hash(); nqp::bindkey(h, "foo", 42); my \x = nqp::clone(h); nqp::bindkey(h, "foo", 43); nqp::atkey(x, "foo").say | |||
| camelia | 42 | ||
| disbot6 | <antononcube> @Voldenet Will try it out later today. | 17:31 | |
| <librasteve> o/ ... really appreciate all the support on the advent posts ... we have 18 either delivered or scheduled ... so just 6 left to find ... I can take one more of those (which puts anton and i level pegging on total of 4) ... so, please can folk come forward with a couple more ... second or third installments are welcome! ??? | 17:48 | ||
|
17:51
librasteve_ joined
|
|||
| disbot6 | <librasteve> korvo: please can you share your email address with me - i am librasteve@furnival.net - then i can set you up woth author perms on the advent wordpress site (that is the easiest) ... follow the info at CONTRIBUTING.md for how to do raku code hiliting ... if you prefer markdown, then please PR your article to the 2025 articles dir on GH and I can migrate to wordpress | 17:54 | |
| <librasteve> i am just finalysing my post for tomorrow - so hopefully korvo and patcikb can cover the 14,15 between you (please update the authors.md if you decide to switch) --- otherwise small beads of cold sweat are forming on my palms | 17:56 | ||
| patrickb | I'd like to claim 21 and tomorrow | 17:59 | |
| disbot6 | <librasteve> perfect - thanks | ||
| <librasteve> i am on the site - doing the PR now | 18:00 | ||
| <librasteve> do you have workgin titles, maybe? | |||
| Geth | advent/main: 2ca4d18dc3 | librasteve++ (committed using GitHub Web editor) | raku-advent-2025/authors.md add ptrickb for 14 and 21 |
18:02 | |
| disbot6 | <librasteve> I'll leave it to you to add the titles when you get a chance | ||
| <librasteve> I am practically done with my next for tomorrow, so you are in for the 14 and 21 | 18:03 | ||
| korvo | librasteve_: cds@corbinsimpson.com will work. I will do my best to make the formatting look correct. Is a link to gist.github.com acceptable for sharing the whole script, or should I inline it? I figured it was way too long to inline. | ||
| disbot6 | <librasteve> cool - invitation sent - I think embedding a few 5-10 line sections is fine - more than that then sure, just link out to a gist (gh has raku hiliting if you use the right file extension) | 18:05 | |
| Geth | advent/main: 7b63bb019d | librasteve++ (committed using GitHub Web editor) | raku-advent-2025/authors.md add librasteve 4th on 20th |
18:06 | |
| disbot6 | <librasteve> getting there - only 3 coveted slots left - grab yours while you can! | ||
| <antononcube> New | 19:18 | ||
| <antononcube> Raku Advent animation: imgur.com/sc8dTs0 | |||
| Geth | advent/main: 67e7d628fe | librasteve++ (committed using GitHub Web editor) | raku-advent-2025/authors.md schedule tomorrow |
19:28 | |
| lizmat | antononcube are you sure that is the correct url ? | 19:32 | |
| korvo: with github.com/rakudo/rakudo/commit/011c1148d7 the benchmark now runs at 37.57 seconds for me (down from 51.34) so about 27% faster | 19:42 | ||
| still no explanation for the $x / $y versus nqp::div_n($x,$y) difference: it *should* just inline to that, getting the 25.67 performance | 19:44 | ||
| korvo | lizmat: And it's shorter, too! | 19:45 | |
| lizmat | the shorter one is the slower one :-( | ||
| korvo | Oh, I mean that your commit saves two lines. | 19:48 | |
| lizmat | ah, yes :-) | ||
| I think this is as much as I can do for this benchmark | 19:50 | ||
| & | |||
| korvo | 27% over two days is amazing, though. | 19:53 | |
| Voldenet | and that's one of the fixes that didn't even need moar-level optimizations :> | 20:21 | |
|
20:46
hankache joined
|
|||
| disbot6 | <antononcube> @lizmat it is the correct link. But imgur is being obnoxious about it. | 20:48 | |
| <antononcube> (Just tried to follow the link on my phone.) | 20:49 | ||
|
20:49
xinming left
20:50
xinming joined
21:12
MoC left
21:26
hankache left
21:38
melezhik left
21:52
abraxxa-home joined
22:04
abraxxa-home left
|
|||
| disbot6 | <.landyacht.> Has anyone had luck getting DBDish::ODBC working on Windows 10? I can’t install it because it can’t find odbc.dll, and I’m sure I have ODBC libs installed somewhere but am having trouble finding them with the File Explorer search - plenty of DLLs that are almost named odbc.dll, but not the thing itself… curious if anyone knows the standard location for that lib on win10 | 22:22 | |
| <.landyacht.> I do have odbc32.dll though, hm | 22:26 | ||
| Geth | ¦ App-Rakubrew: patrickbkr self-assigned Can’t use zef on windows? github.com/Raku/App-Rakubrew/issues/91 | 22:45 | |
| disbot6 | <.landyacht.> Got it working by making a symlink called odbc.dll to odbc32.dll | 22:59 | |
| <.landyacht.> Well, maybe… now it appears the proto method for connect in ODBC doesn’t match one of the candidates, too few positionals in the proto… | 23:00 | ||
| <.landyacht.> Yes, we have data! | 23:36 | ||