<< 23-03-2026 >>
00:43:09*beholders_eye quit (Ping timeout: 272 seconds)
01:09:23*Mister_Magister quit (Quit: bye)
01:11:56*Mister_Magister joined #nim
01:46:08*rockcavera joined #nim
01:58:41*rockcavera quit (Ping timeout: 244 seconds)
02:20:35*rockcavera joined #nim
02:20:35*rockcavera quit (Changing host)
02:20:35*rockcavera joined #nim
02:24:50*rockcavera quit (Ping timeout: 248 seconds)
05:33:16FromDiscord<leeeee2976> Is memory management already solved problem on Nim? It seems a lot of C people started to adopt Arena approach. I am curious if Nim's TLSF algorithm implementation makes the arena kind of management unncessary
05:38:53FromDiscord<sh1be> sent a long message, see https://pasty.ee/gCmLgyvT
05:42:04FromDiscord<planetis_m> In reply to @leeeee2976 "Is memory management already": yes. freaking arenas. and we also have mimalloc support for multithreading code.
05:43:01FromDiscord<planetis_m> arena's is just twitter trends imo, they will regret it eventually
05:44:55FromDiscord<leeeee2976> In reply to @planetis_m "arena's is just twitter": Could you share some insight on what is the issue on arena usage? I
05:45:03FromDiscord<leeeee2976> (edit) removed "I"
05:46:07FromDiscord<leeeee2976> Well I don't have a CS degree but I need to deal with a lot of research codes. So I have been studying a lot of these concepts to make the number crunching go faster
05:50:22FromDiscord<planetis_m> you need to pass everywhere extra arguments. unless you make a immediate mode gui that is reconstructed in every frame then you have no use of arenas. I dont know what number crunching you mean and how it can arena be beneficial but it does sound niche
05:59:04*mrinsane quit (Ping timeout: 245 seconds)
06:00:09FromDiscord<planetis_m> For most code there's no benefit, mimalloc is already fast and uses its own per thread cache anyway.
06:00:20FromDiscord<planetis_m> (edit) "For most ... code" added "multithreaded"
06:00:59FromDiscord<planetis_m> (edit) "cache" => "caches"
06:29:22*emery quit (Ping timeout: 268 seconds)
06:56:22*Lord_Nightmare quit (Quit: ZNC - http://znc.in)
06:58:43*Lord_Nightmare joined #nim
07:10:01*Jjp137 quit (Quit: Leaving)
07:12:52*Jjp137 joined #nim
07:59:39Amun-Raarena allocators have one problem: they are seen as a continuous block of memory by the system; this may lead to leaking data if there's a bug in allocator
08:07:33FromDiscord<nnsee> which system? and how does that differ from, say, libc malloc?
08:08:49Amun-Raevery call to malloc allocates separate block of memory controlled by the OS
08:09:30Amun-Raarena allocator make one big alloc and assign chunk of it
08:09:42Amun-Ramakes*
08:10:43Amun-Raif there's a bug in the allocator OS security system way not detect it
08:12:47Amun-Raarena makes sanitizer detect less cases, because of no per object free - asan won't (or may not) catch use after free
08:13:18Amun-Raasan can't insert redzones between allocations
08:13:46Amun-Raubsan can be confused by object life time
08:14:07Amun-Rathose are worst case scenarios ofc, but still
08:14:11FromDiscord<nnsee> sent a long message, see https://pasty.ee/lkSxYhhA
08:15:30Amun-Ramalloc is implementation defined by the standard; I'm talking about the way it's usually implemented
08:15:36FromDiscord<_russianlifts> https://youtu.be/xt1KNDmOYqA?si=qyhhl2AtFfObfMvf
08:15:49Amun-Rathere's no heap and stack in C standard, too
08:15:51FromDiscord<_russianlifts> casey talked about this specifically recently hahaha
08:16:41Amun-Ra_russianlifts: I don't know the channel, thanks for the link, added to my to-watch list
08:18:21FromDiscord<_russianlifts> sent a long message, see https://pasty.ee/rSRYRxjD
08:20:57Amun-Rawhat I meant was arena allocators are not panacea for everything; there are pros and cons
08:42:56FromDiscord<nnsee> In reply to @Amun-Ra "arena makes sanitizer detect": if you're running ASAN you're likely running a debug build to begin with in which case you can just fall through to regular malloc in debug builds to catch uafs/oobs/whatever - those would be triggered regardless of the underyling allocator so it doesn't matter if you're using libc malloc or an arena allocator, if this is something you're truly concerned with
08:43:19*emery joined #nim
08:43:40FromDiscord<nnsee> there's also literally nothing stopping the arena allocator from setting up poisoned regions manually
08:43:46FromDiscord<nnsee> asan has an API for this
08:44:45FromDiscord<nnsee> i don't see how arena allocators would affect ubsan, but maybe i'm missing something here
08:54:54*Jjp137 quit (Ping timeout: 245 seconds)
08:58:34FromDiscord<planetis_m> Well ASan has the machinery to poison/unpoison memory regions, so it short of works
08:59:18FromDiscord<planetis_m> The issue is how you move stuff between threads, you don't really. You need to change the ownership of the whole arena
09:00:02FromDiscord<planetis_m> IMO it's only good for very niche things, it's not a general purpose solution
09:00:18FromDiscord<planetis_m> Certainly shouldn't be part of a language
09:00:26FromDiscord<planetis_m> A library maybe
09:03:02FromDiscord<nnsee> of course, it's definitely not a one size fits all solution, but it's not something that shouldn't be considered if the code architecture permits it and if performance is required (or if you want it for lifetime-related reasons)
09:04:18FromDiscord<planetis_m> Are there any benchmarks between mimalloc vs arenas? What kind of performance are we talking about?
09:05:18*emery quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
09:10:57FromDiscord<nnsee> sent a long message, see https://pasty.ee/VxRkrUwk
09:11:39FromDiscord<nnsee> not to talk about cache locality, etc
09:14:53*xet7 quit (Remote host closed the connection)
09:15:42FromDiscord<planetis_m> Well, I think I might make a benchmark using this: https://github.com/planetis-m/naylib/blob/main/src/rmem.nim⁠�, but again, I doubt it matters in most cases. The code is needlessly complicated—we have proper lifetimes in Nim; we don’t need arenas.
09:15:50FromDiscord<planetis_m> (edit) "https://github.com/planetis-m/naylib/blob/main/src/rmem.nim⁠�," => "https://github.com/planetis-m/naylib/blob/main/src/rmem.nim⁠," | "complicated—we" => "complicated,we"
09:20:15*xet7 joined #nim
09:32:55*beholders_eye joined #nim
10:01:56*xet7 quit (Ping timeout: 256 seconds)
10:07:34FromDiscord<mratsim> In reply to @planetis_m "Are there any benchmarks": arenas are faster. less overhead. But they are niche.↵↵This is an arena based on Mimalloc design: https://github.com/mratsim/weave/blob/master/weave/memory/memory_pools.nim
10:08:45FromDiscord<mratsim> It should be pretty easy to make standalone, most of the imports are for `debug:` and other design by contract macros. Plus one for multithreaded channels/queues for managing multithreaded deallocation
10:09:33FromDiscord<mratsim> You have a bench vs Nim createShared at the bottom: https://github.com/mratsim/weave/blob/master/weave/memory/memory_pools.nim#L646-L891
10:13:33*xet7 joined #nim
10:29:11*GnuYawk19 joined #nim
10:29:33*cornfeedhobo_ joined #nim
10:30:16*cornfeedhobo quit (Ping timeout: 264 seconds)
10:30:16*cornfeedhobo_ is now known as cornfeedhobo
10:32:21*emery joined #nim
10:34:03*GnuYawk1 quit (Ping timeout: 264 seconds)
10:34:04*GnuYawk19 is now known as GnuYawk1
10:44:08FromDiscord<planetis_m> well its never just bumping a pointer, but if your design is based on mimalloc, well my obvious question is how is it faster?
10:50:08*gshumway quit (*.net *.split)
10:51:08*gshumway joined #nim
11:02:10*xet7 quit (Ping timeout: 248 seconds)
11:05:34*Jjp137 joined #nim
11:14:55*xet7 joined #nim
12:03:59*xet7 quit (Ping timeout: 272 seconds)
12:15:45*xet7 joined #nim
12:30:36*Jjp137 quit (Ping timeout: 246 seconds)
13:04:04*xet7 quit (Ping timeout: 245 seconds)
13:07:30*beholders_eye quit (Ping timeout: 255 seconds)
13:16:26*xet7 joined #nim
14:11:30*xet7 quit (Remote host closed the connection)
14:16:39*beholders_eye joined #nim
14:44:02*Jjp137 joined #nim
14:48:17*lesssalt quit (Ping timeout: 252 seconds)
15:00:42*lesssalt joined #nim
15:51:32*Jjp137 quit (Ping timeout: 252 seconds)
16:08:56*mrinsane joined #nim
16:15:10*mrinsane quit (Ping timeout: 245 seconds)
16:20:09*xet7 joined #nim
16:52:57*beholders_eye quit (Ping timeout: 255 seconds)
17:08:37*xet7 quit (Ping timeout: 272 seconds)
17:19:07*itwrx joined #nim
17:19:50*xet7 joined #nim
17:23:14*itwrx quit (Client Quit)
18:00:11*beholders_eye joined #nim
18:05:00*Jjp137 joined #nim
18:26:53FromDiscord<nocturn9x> uhm
18:27:05FromDiscord<nocturn9x> I'm working on my language and it's written in nim
18:27:10FromDiscord<nocturn9x> I have a test suite for the C codegen
18:27:17FromDiscord<nocturn9x> and sometimes nim takes several MINUTES just to compile it
18:27:49FromDiscord<nocturn9x> like it takes less time to build my 6k+LOC chess engine
18:28:01FromDiscord<nocturn9x> than this ~1300 line test suite file
18:30:22FromDiscord<nocturn9x> huh, seems like `--exceptions:setjmp` was the problem??
18:37:16*mrinsane joined #nim
19:08:46*xet7 quit (Ping timeout: 256 seconds)
19:21:33*xet7 joined #nim
20:10:35*xet7 quit (Ping timeout: 252 seconds)
20:22:27*xet7 joined #nim
21:16:56*hygo joined #nim
22:12:40*xet7 quit (Ping timeout: 276 seconds)
22:24:31*xet7 joined #nim
22:29:32*rockcavera joined #nim
23:13:07*xet7 quit (Ping timeout: 276 seconds)
23:25:24*xet7 joined #nim