|
Sweeper posted:which malloc/free corner cases are you referring to? and while RAII isn't some magic bullet, it is a good concept. It allows for some great stuff like unique_ptr. There are many things wrong with c++, but RAII isn't one of em. I'm not sure what hairy profiling issues you are thinking of, but in my experience it makes it more obvious when you are allocating/deallocating memory. Perhaps someone doing stupid poo poo in destructors is causing you problems? heap fragmentation sucks poo poo, even when the heap is handled by malloc/free and not a garbage collector Sweeper posted:If you need extremely low latency and high throughput (the niche that c++ lives in), I'd say there is a very small change you want to use a gc. It simply doesn't have the determinism you need to not have a pause at just the wrong time and kill your p100. as with all other gc-related items, "it depends" it is very much possible to control 99.9th percentile pause times. there are even garbage collectors with deterministic pause times. but it is a tradeoff against other behaviors, as listed in my prior post and, of course, the actual time spent in malloc() and free() depends on total application behavior, not the size or behavior of the specific object or thread doing the allocation it is not as simple as "i need determinism, ergo i need c++"
|
#
?
Oct 20, 2018 17:36
|
|
|
|
| # ? May 22, 2024 13:07 |
|
|
Arenas are great, but surprisingly often you cannot get a non-trivial guarantee on the max alloc size.
|
|
#
?
Oct 20, 2018 17:40
|
|
|
time to recycle views on garbage collection
|
|
#
?
Oct 20, 2018 17:56
|
|
|
Cybernetic Vermin posted:while that stuff will usually just be done on a gc thread along with other things it will be outside the "stop the world" phase of the gc, so it is usually not a noticeable problem in any way I'm specifically asking about running destructors and freeing memory off the main thread in a non-GC scenario.
|
|
#
?
Oct 20, 2018 18:38
|
|
|
tef posted:time to recycle views on garbage collection the nursery always needs a thorough reaping
|
|
#
?
Oct 20, 2018 18:43
|
|
|
redleader posted:don't be loving stupid. how dare you even think of having more than one memory management paradigm in a language thanks for the reminder that c++/cli exists
|
|
#
?
Oct 20, 2018 18:47
|
|
|
pseudorandom name posted:I'm specifically asking about running destructors and freeing memory off the main thread in a non-GC scenario. I could see issues with running non-trivial destructors on some random rear end thread other than the one it was created in tbh
|
|
#
?
Oct 20, 2018 18:51
|
|
|
feedmegin posted:I could see issues with running non-trivial destructors on some random rear end thread other than the one it was created in tbh Oh, yeah, if you're e.g. using RAII for lock release this would be a disaster, but I'm curious if anybody has every tried it in experimental languages or whatever.
|
|
#
?
Oct 20, 2018 19:00
|
|
|
tef posted:time to recycle views on garbage collection better than talking build systems and producing a byte-for-byte identical conversation
|
|
#
?
Oct 20, 2018 22:20
|
|
|
pseudorandom name posted:I'm specifically asking about running destructors and freeing memory off the main thread in a non-GC scenario. you have pools and arenas available, for one thing. also I'm not sure that a thread-safe enqueue is going to be cheaper than free(). atomics are expensive
|
|
#
?
Oct 20, 2018 23:08
|
|
|
Kevin Mitnick P.E. posted:also I'm not sure that a thread-safe enqueue is going to be cheaper than free(). theres a reason the disruptor pattern exists and happens to be fast as poo poo
|
|
#
?
Oct 20, 2018 23:11
|
|
|
it's a ring buffer and doesn't use allocation woop
|
|
#
?
Oct 20, 2018 23:13
|
|
|
Helicity posted:theres a reason the disruptor pattern exists and happens to be fast as poo poo atomics are still expensive and i'd be somewhat surprised if modern mallocs used any on the fast path
|
|
#
?
Oct 20, 2018 23:19
|
|
|
i was essentially agreeing with your statement about enqueue if you dont run into queues and locks being a bottleneck, its probably not that interesting of a pattern i suppose
|
|
#
?
Oct 20, 2018 23:20
|
|
|
ah
|
|
#
?
Oct 20, 2018 23:24
|
|
|
pseudorandom name posted:I'm specifically asking about running destructors and freeing memory off the main thread in a non-GC scenario. i mean, theoretically, this is a great idea, because items that are dead won't have any existing references, except of course if your finalizer creates zombies anyway, here's the thing - rust has garbage collection, it has managed memory, it just doesn't do tracing, - gc has come forward in leaps and bounds since 1996 - rust has opt in dynamic ref counting (& atomic variants) already and people have been working on #[derive(Trace)] like stuff since forever - but yeah, reference counting adds about 10-20% to the runtime costs of a program - you need to end up doing things like bump/line allocators, deferred reference counting, and other fancy pants poo poo - and the other problem is that you need to do incremental deallocation, or you get long pauses in your application it turns out writing performant code isn't made easier by avoiding the gc who knew
|
|
#
?
Oct 20, 2018 23:33
|
|
|
prisoner of waffles posted:better than talking build systems and producing a byte-for-byte identical conversation
|
|
#
?
Oct 21, 2018 00:32
|
|
|
tef posted:i mean, theoretically, this is a great idea, because items that are dead won't have any existing references, except of course if your finalizer creates zombies I really really hope you’re not saying that not needing to call free is the same as GC
|
|
#
?
Oct 21, 2018 00:33
|
|
|
Kevin Mitnick P.E. posted:I really really hope you’re not saying that not needing to call free is the same as GC quack
|
|
#
?
Oct 21, 2018 01:45
|
|
|
gonna get some cutting edge cs research going in the yospos smart programmers thread
|
|
#
?
Oct 21, 2018 01:48
|
|
|
rust literally does one bit ref counting (the drop flag), and uses compile time checks to enforce the count never exceeds 1 ref counting and tracing are duals, to the point where any _serious_ gc in the last ten-twenty years has some overlap https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf i mean, from a coarse view point: reference counting scans dead objects (to deallocate), tracing scans live ones and there's literally no issue in combining both https://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon01Concurrent.pdf but yeah i'm saying, weirdly enough, reference counting is a form of garbage collection
|
|
#
?
Oct 21, 2018 01:54
|
|
|
redleader posted:gonna get some cutting edge cs research going in the yospos smart programmers thread http://users.cecs.anu.edu.au/~steveb/pubs/papers/rcix-oopsla-2013.pdf here's a slightly less old paper
|
|
#
?
Oct 21, 2018 01:56
|
|
|
it's the one about 'so how can we get reference counting to within the performance of gc'
|
|
#
?
Oct 21, 2018 01:56
|
|
|
tef posted:rust literally does one bit ref counting (the drop flag), and uses compile time checks to enforce the count never exceeds 1 I don’t believe it’s useful to redefine GC as “don’t need to call free” but I am too tired to call you names over it
|
|
#
?
Oct 21, 2018 02:23
|
|
|
raminasi posted:thanks for the reminder that c++/cli exists does this compile to the CLR bytecode (or whatever it's called) that "regular" languages like c# compile to? or can you do wacky mix and match stuff with both CLR and traditional machine code
|
|
#
?
Oct 21, 2018 02:53
|
|
|
tef posted:time to recycle views on garbage collection prisoner of waffles posted:better than talking build systems and producing a byte-for-byte identical conversation lol
|
|
#
?
Oct 21, 2018 07:48
|
|
|
Kevin Mitnick P.E. posted:you have pools and arenas available, for one thing. also I'm not sure that a thread-safe enqueue is going to be cheaper than free(). atomics are expensive the starter question was about doing large deallocations on a thread, so compare more an enqueue to save 30+ of them, or whatever number you like Dylan16807 fucked around with this message at 08:26 on Oct 21, 2018 |
|
#
?
Oct 21, 2018 08:19
|
|
|
tef posted:but yeah i'm saying, weirdly enough, reference counting is a form of garbage collection I sincerely hope that anyone who cares about the meanings of the terms understands this like, the folks who created OpenStep’s autorelease pool mechanism, and then autozone, and then ARC for ObjC and then Swift certainly did
|
|
#
?
Oct 21, 2018 09:12
|
|
|
you ever wish we all could just confine ourselves to finite state machines and forget about memory forever
|
|
#
?
Oct 21, 2018 09:44
|
|
|
ultimately all machines are finite state
|
|
#
?
Oct 21, 2018 09:49
|
|
|
technically all machines are made of analog components following the digital discipline so they're not really finite state unless the universe is discretized send tweet
|
|
#
?
Oct 21, 2018 10:32
|
|
|
the problem with garbage collectors is that they are usually black boxes because they are designed around a "don't worry about memory, we'll take care of it" philosophy reference counting, on the other hand (I know it's also a garbage collector, bear with me) while not a magic bullet, is easier to understand and performance issues are easier to troubleshoot and work around I have a friend who works at a company where they build test benches and the software is VB .net, when they deal with massive amounts of real time data acquisition they can often run into latency issues caused by the garbage collector because it waits too long to collect things and then do it all at once he told me stories of debugging this kind of things that are a hundred times scarier than anything I ever experienced with c++ of course malloc/free is also a mysterious black box but I think tracing garbage collectors are much worse
|
|
#
?
Oct 21, 2018 11:31
|
|
|
ya we had huge problems with GC when running reports at a previous job hundreds of thousands of object trees per week being boiled down to lineitem objects that were eventually serialized in multiple files & formats running the quarterlies took like 10+ hrs and from what I remember of the logs, I wanna say like half was just gc
|
|
#
?
Oct 21, 2018 12:20
|
|
|
Lutha Mahtin posted:does this compile to the CLR bytecode (or whatever it's called) that "regular" languages like c# compile to? or can you do wacky mix and match stuff with both CLR and traditional machine code The latter.
|
|
#
?
Oct 21, 2018 12:38
|
|
|
while not suitable in every setting i always react to complaints about the latency of gc by suspecting that the programmers who are having the issues would have plenty of issues in any other settings as well. some things are realtime sensitive, but having done stock exchanges in java, often replacing one done in c/c++ while offering far better latency, i don't expect that many of those hard cases come up
|
|
#
?
Oct 21, 2018 13:14
|
|
|
no doubt the code was awful in many ways but the gc caused the most trouble
|
|
#
?
Oct 21, 2018 13:21
|
|
|
i see a decent number of devs solve network/cpu/thread bottlenecks with many-thousands-of-rps-apis and then come to memory issues and get totally flummoxed because that magical black box isnt working exactly the way they want it any longer and theyve never had to worry about being memory efficient because 32gb ram is dirt cheap
|
|
#
?
Oct 21, 2018 13:24
|
|
|
what if it's programmers blaming the one thng they don't understand & can't control meaningfully like these are the sort of people who put while loops in critical sections
|
|
#
?
Oct 21, 2018 14:25
|
|
|
Zlodo posted:the problem with garbage collectors is that they are usually black boxes because they are designed around a "don't worry about memory, we'll take care of it" philosophy how do you feel about your processor's cache
|
|
#
?
Oct 21, 2018 15:55
|
|
|
|
| # ? May 22, 2024 13:07 |
|
|
Internet Janitor posted:how do you feel about your processor's cache it's great until it leaks secrets
|
|
#
?
Oct 21, 2018 16:49
|
|
