|
Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
|
04:10
guifa left
|
|||
| lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/05/05/2025-...d-dancing/ | 10:35 | |
|
10:43
guifa joined
|
|||
| timo | "read" takes an unsigned size_t for the amount of bytes you want to read, and returns an ssize_t with the actual number of bytes read (so that it can also return -1 in case of an error), so what happens when your amount of read bytes fits in uint64 but not in the positive half of int64 … | 15:05 | |
| Voldenet | there's two options: you get size_t excluding -1 or you never get more bytes read than SSIZE_MAX | 15:27 | |
| timo | indeed | ||
| the size we put in is more of a "request" anyway | |||
| Voldenet | it's a bit ridiculous that this is implementation specific in posix | 15:28 | |
| timo | and even then, SSIZE_MAX is quite a large amount of data to read from a file. at that point, mmapping the file is probably wiser, so the user might have a use case where going to APIs that are closer to the platform they are targeting | ||
| Voldenet | Actually it doesn't have to be a large amount, but it depends on whether you like sci-fi or not | 15:36 | |
| Geth | MoarVM/less_memory_waste_binslurp_and_normalizecodes: 0288cf1751 | (Timo Paulssen)++ | 2 files In read_fhb aka nqp::readfh don't keep too-large buffers around. We were allocating as much space as the caller was asking for, but in rakudo for slurp we are passing 1 megabytes as the size by default. |
15:39 | |
| MoarVM/less_memory_waste_binslurp_and_normalizecodes: bcf3fa6c88 | (Timo Paulssen)++ | src/strings/normalize.c normalizecodes: allow re-using codepoints buffer without leaking Passing a buffer object in that already had contents used to drop the buffer on the floor without freeing it. Also, we weren't setting ssize, which could in theory make vmarray misbehave. |
|||
| MoarVM: timo++ created pull request #1938: Less memory waste binslurp and normalizecodes |
15:41 | ||
| timo | you can see how for the extreme case of a two-byte file, this takes just 1/10th of the time, and hundreds of megabytes less peak memory | 15:42 | |
|
16:09
japhb left
|
|||
| Geth | MoarVM/less_memory_waste_binslurp_and_normalizecodes: 9a84c07b72 | (Timo Paulssen)++ | 2 files In read_fhb aka nqp::readfh don't keep too-large buffers around. We were allocating as much space as the caller was asking for, but in rakudo for slurp we are passing 1 megabytes as the size by default. |
16:12 | |
| MoarVM/less_memory_waste_binslurp_and_normalizecodes: 78b08fb58b | (Timo Paulssen)++ | src/strings/normalize.c normalizecodes: allow re-using codepoints buffer without leaking Passing a buffer object in that already had contents used to drop the buffer on the floor without freeing it. Also, we weren't setting ssize, which could in theory make vmarray misbehave. |
|||
| timo | ^- fixed typo that nine++ pointed out | 16:13 | |
|
16:22
japhb joined
16:34
japhb left
16:35
japhb joined
17:04
japhb left
17:11
japhb joined
17:30
japhb left
17:54
japhb joined
19:02
japhb left,
japhb joined
19:13
japhb left
19:28
japhb joined
19:44
japhb left
19:50
japhb joined
20:04
japhb left
20:10
japhb joined
20:19
japhb left,
japhb joined
|
|||
| patrickb | I'm working on adding variadic arg support to native call. I want to be able to add a trait `is variadic` to a routine with the `is native` trait. In the end I want to set a Boolean field in MVMNativeCallBody whether the trait was there or not. | 20:25 | |
| It seems the buildnativecall op can't be bent to pass on another bit of info. | 20:26 | ||
|
20:28
japhb left
|
|||
| patrickb | What's the best option forward? Create a new op buildnativecall2 that has another arg? Add a new op buildvariadicnativecall that has the same args but is to be called only for variadic functions? Something entirely different? | 20:28 | |
|
20:28
japhb joined
|
|||
| timo | right, ops can't have their number of arguments changed without making bytecode "incompatible"; now that we have syscalls however, it's probably fine to turn buildnativecall into a syscall, and those can be variadic | 20:29 | |
| we could also have a syscall that sets the variadic number on an existing nativecall object that buildnativecall spat out? | 20:30 | ||
|
20:44
japhb left,
japhb joined
21:19
japhb left
21:21
japhb joined
|
|||
| patrickb | It's not a number, but only a boolean. (Is it variadic function at all?) | 21:25 | |
| Hm. I'm a bit unsure about how back compat is meant to work. Could I just adapt the buildnativecall op by just adding another arg? I can't because moar should be able to run old byte code, right? | 21:27 | ||
| Syscalls are loads slower that ops, right? In this case it'd be fine, because buildnativecall has no potential at all to ever be hot code, right? | 21:28 | ||
| So the idea could be to not add a buildnativecall2 op, but a buildnativecall syscall instead. Keep the op for a while and get rid of it in some time. Having a syscall instead of another op has the advantage of more flexibility in the future. For this immediate issue it doesn't make much of a difference, correct? | 21:30 | ||
| timo | no syscalls should not be that much slower than ops | 21:36 | |
| it doesn't make that much a difference right now whether you introduce a new op or a syscall | 21:37 | ||
| but i would strongly lean in the direction of syscall | |||
| patrickb | Ok. I guess I have an idea what to do then. Thanks! | 21:46 | |
| Off to bed for me now though... 'night! | |||
| timo | good night! | 21:53 | |
|
22:47
japhb left
22:48
japhb joined
23:01
japhb left
23:02
japhb joined
23:54
benchable6 left,
benchable6 joined
|
|||