p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

akadajet: Sep 14, 2003

Helicity posted:

https://github.com/withoutboats/shifgrethor

aw yeah

what does rust do for memory management today? or do i not want to open that box?

# ? Oct 19, 2018 14:52

Adbot: ADBOT LOVES YOU

# ? Jun 11, 2024 23:32

cinci zoo sniper: Mar 15, 2013

akadajet posted:

what does rust do for memory management today? or do i not want to open that box?

isnt the point of the language that it's nothing

# ? Oct 19, 2018 14:54

Sweeper: Nov 29, 2007; The Joe Buck of Posting; Dinosaur Gum

Helicity posted:

https://github.com/withoutboats/shifgrethor

aw yeah

why would you want GC in a language that does the right thing and drops unowned data

what is this person doing with their life

# ? Oct 19, 2018 14:56

luchadornado: Oct 7, 2004; A boombox is not a toy!

akadajet posted:

what does rust do for memory management today? or do i not want to open that box?

it inserts allocation/deallocation calls at compile time as part of its "lifetime" concept, although if you need reference counting for whatever reason it's available

# ? Oct 19, 2018 14:57

luchadornado: Oct 7, 2004; A boombox is not a toy!

key point is that there was no tracing/sweeping gc (until withoutboats started doing "research")

# ? Oct 19, 2018 15:00

Vanadium: Jan 8, 2005

Don't knock GC until you've checked out the hoops eg. the crossbeam lib has to jump through to get things any p-lang gives you for free, with their epoch stuff.

Then feel free to knock GC but it's not like a GC lib means people will write radically different rust.

# ? Oct 19, 2018 15:26

CPColin: Sep 9, 2003; Big ol' smile.

That Rust garbage collector posted:

What is the state of the project?

Code has been written, sometimes frantically.

# ? Oct 19, 2018 15:30

Nomnom Cookie: Aug 30, 2009

what is my complicated language with a pissy compiler missing, i know, GC stalls

# ? Oct 19, 2018 16:59

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

yes i'm sure the goal of the author is to have gc through entire codebases

god forbid you'd want to make things like embedded scripting easier

# ? Oct 19, 2018 19:30

redleader: Aug 18, 2005; Engage according to operational parameters

don't be loving stupid. how dare you even think of having more than one memory management paradigm in a language

# ? Oct 19, 2018 23:00

Captain Foo: May 11, 2004; we vibin'
we slidin'
we breathin'
we dyin'

redleader posted:

don't be loving stupid. how dare you even think of having more than one memory management paradigm in a language

SLUB-Nigurath

# ? Oct 19, 2018 23:26

Sweeper: Nov 29, 2007; The Joe Buck of Posting; Dinosaur Gum

redleader posted:

don't be loving stupid. how dare you even think of having more than one memory management paradigm in a language

unironically this

# ? Oct 19, 2018 23:52

Nomnom Cookie: Aug 30, 2009

right so then why does rust have such strong restrictions on ownership and all the lifetime crap

to guarantee use-after-free doesn't happen without needing GC

because mozilla can't do a browser in c++ without dangling pointers everywhere

and now rust is getting GC anyway

this is very lol

# ? Oct 20, 2018 00:32

Lutha Mahtin: Oct 10, 2010; Your brokebrain sin is absolved...go and shitpost no more!

Kevin Mitnick P.E. posted:

because mozilla can't do a browser in c++ without dangling pointers everywhere

people like what they like

# ? Oct 20, 2018 00:36

luchadornado: Oct 7, 2004; A boombox is not a toy!

Kevin Mitnick P.E. posted:

and now rust is getting GC anyway

this is very lol

no one in their right mind is going to use this, and rust is still a cool language

# ? Oct 20, 2018 00:58

Arcsech: Aug 5, 2008

Kevin Mitnick P.E. posted:

and now rust is getting GC anyway

this is very lol

I mean

if you count a library, I guess

but you can write a dumbshit library in any language, I mean, some joker wrote a thing that lets you run javascript as a server

# ? Oct 20, 2018 01:15

prisoner of waffles: May 8, 2007; Ah! well a-day! what evil looks
Had I from old and young!
Instead of the cross, the fishmech
About my neck was hung.

yeah, there's nothing inconsistent about building a GC system in rust. the point of the language is to be a memory-safe systems language, not "GC bad, precise good".

I'm not sure about this assertion being necessarily true, but a good GC system can probably outperform ref counting on some problems (and vice versa)

# ? Oct 20, 2018 01:32

Ellie Crabcakes: Feb 1, 2008; Stop emailing my boyfriend Gay Crungus

quote:

some joker wrote a thing that lets you run javascript as a server

hosed up if true

# ? Oct 20, 2018 01:34

mystes: May 31, 2006

prisoner of waffles posted:

I'm not sure about this assertion being necessarily true, but a good GC system can probably outperform ref counting on some problems (and vice versa)

GC can perform better than reference counting when you have cycles because stuff will actually get garbage collected.

# ? Oct 20, 2018 01:34

MononcQc: May 29, 2007

if you do refcounting and a vast number of objects are referred to from a single place, and that value is freed, then you may need to free the vast number of objects at once which could possibly stop the world and hold up the program. Some real-time or generational GCs could in some circumstances perform better and more predictably (latency-wise at least) than refcounting.

# ? Oct 20, 2018 02:20

redleader: Aug 18, 2005; Engage according to operational parameters

gc better than refcounting, got it

# ? Oct 20, 2018 05:07

Ralith: Jan 12, 2011; I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

Helicity posted:

it inserts allocation/deallocation calls at compile time as part of its "lifetime" concept

this is kind of a weird way to say "some data structures in the standard library call malloc or w/e when it makes sense to do so, and so can you." there's no compiler magic involved.

# ? Oct 20, 2018 05:17

tinaun: Jun 9, 2011; tell me...

rusts drop checking rules can get really hairy when types holding lifetimes are involved, though

also its the source of the clunkiest syntax ever

quote:

In the meantime, there is an unstable attribute that one can use to assert (unsafely) that a generic type's destructor is guaranteed to not access any expired data, even if its type gives it the capability to do so.

That attribute is called may_dangle and was introduced in RFC 1327. To deploy it on the Inspector example from above, we would write:
code:
struct Inspector<'a>(&'a u8, &'static str);

unsafe impl<#[may_dangle] 'a> Drop for Inspector<'a> {
    fn drop(&mut self) {
        println!("Inspector(_, {}) knows when *not* to inspect.", self.1);
    }
}

tinaun fucked around with this message at 05:28 on Oct 20, 2018

# ? Oct 20, 2018 05:23

Lutha Mahtin: Oct 10, 2010; Your brokebrain sin is absolved...go and shitpost no more!

MononcQc posted:

if you do refcounting and a vast number of objects are referred to from a single place, and that value is freed, then you may need to free the vast number of objects at once which could possibly stop the world and hold up the program. Some real-time or generational GCs could in some circumstances perform better and more predictably (latency-wise at least) than refcounting.

i'm sure this is a really dumb noob question but, why do GC and GC-esuqe systems not defer/stagger the freeing of a shitload of objects versus making the decision "oh we have a shitload of objects to free, better fuckin halt everything until we nuke all of them right this moment"

# ? Oct 20, 2018 05:23

pseudorandom name: May 6, 2007

yeah, I was going to ask about that earlier � is there any precedent for �freeing� an object to throw it on a queue and another thread taking care of running the destructor? i.e. I guess GC finalizers but in a non-GC system

# ? Oct 20, 2018 05:29

Nomnom Cookie: Aug 30, 2009

Lutha Mahtin posted:

i'm sure this is a really dumb noob question but, why do GC and GC-esuqe systems not defer/stagger the freeing of a shitload of objects versus making the decision "oh we have a shitload of objects to free, better fuckin halt everything until we nuke all of them right this moment"

well some of them kinda do or at least try to do the heavy lifting concurrently with app threads. there�s always a risk of app threads allocating faster than your GC can keep up and then it�s STW time though

except for azul�s magic GC which I suspect mainly works by putting your throughput in the toilet, enlisting app threads to do GC work interleaved with real work. it does however guarantee no STW ever

# ? Oct 20, 2018 06:00

Nomnom Cookie: Aug 30, 2009

oh and fully STW GC is best for overall throughput so there�s no single best GC algorithm. more like a menu of operational headaches to choose from

# ? Oct 20, 2018 06:02

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Ralith posted:

this is kind of a weird way to say "some data structures in the standard library call malloc or w/e when it makes sense to do so, and so can you." there's no compiler magic involved.

i mean, there�s a ton of compiler magic involved, but it�s generalized to cover arbitrary value consumption/destruction

# ? Oct 20, 2018 06:17

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

Lutha Mahtin posted:

i'm sure this is a really dumb noob question but, why do GC and GC-esuqe systems not defer/stagger the freeing of a shitload of objects versus making the decision "oh we have a shitload of objects to free, better fuckin halt everything until we nuke all of them right this moment"

usually when people say 'garbage collector' they mean a tracing collector. with these you usually scan the stack and then recursively follow pointers to build a graph of all reachable objects on the heap. then you throw out everything else. the expensive thing here is building the graph. once you have that you really want to evict anything on the heap that isn't reachable to save you having to build the graph again for as long as possible

you can improve on this with a generational collector tho. with these you take advantage of the fact that most objects are short lived and are only referenced from the stack and rarely from older objects. collecting just recently allocated objects nets you most of the benefits of collecting everything, but is much faster. you allocate them in one segment of the heap reserved for new objects and then move survivors of garbage collection passes to a different segment. the objects in the "survivor" (or "old") generation are only allowed to contain pointers to other objects in the "survivor" generation, so your runtime needs to intercept all pointer assignments and move anything referenced from the "young" to the "survivor" segment but this allows you to basically ignore the "survivor" generation during gc if you want. you only collect the "survivor" generation when you really need to. you can have multiple levels of this with objects getting promoted to segments that are collected much more rarely as they age

this is how pretty much every garbage collector (note: assuming you don't count reference counting as gc) works in practice, outside of exotics ones designed for very specific use cases or ones for languages like haskell where you can make assumptions about pointers that aren't possible in more mainstream languages

the talent deficit fucked around with this message at 06:36 on Oct 20, 2018

# ? Oct 20, 2018 06:33

Notorious b.s.d.: Jan 25, 2003; by Reene

the tl;dr version: there are several tradeoffs among:

leaving garbage "alive" in the heap, wasting memory
"stopping the world" (pausing)
spending too much cpu time on gc (on multiple threads or one)
scaling to varying heap sizes -- the strategy that handles the first three tradeoffs well in a 500 MB heap almost certainly fails in a 2 TB heap

there is no free lunch in garbage collection, ever. every gc strategy falls down somewhere.

(there is also not a free lunch in avoiding garbage collection: malloc() and free() have extraordinarily unpleasant behaviors in corner cases. the C++ whackadoos who rave about "RAII" are just moving the problem into hairy profiling issues)

# ? Oct 20, 2018 06:41

Cybernetic Vermin: Apr 18, 2005

pseudorandom name posted:

yeah, I was going to ask about that earlier — is there any precedent for “freeing” an object to throw it on a queue and another thread taking care of running the destructor? i.e. I guess GC finalizers but in a non-GC system

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

just getting the things done in one go is good for throughput as well, avoid repeatedly having to basically trash the applications cache state by walking about random dead objects (same issue as with refcounting, which will often in practice turn out extremely expensive since it inserts a lot of pokes at memory which is not in cache and not otherwise useful to have in cache). it may seem like there is no gain in that the gc also wont have the dead objects in cache when it finishes the scan to determine they are dead, but at that point the cache contains mostly junk anyway (i.e. the final bits of the tracing) so it is no loss evicting it

if the thinking is to defer cleaning up objects for a long time to get a huge amount of work done: why not defer the entire gc if you have that kind of memory to spare?

# ? Oct 20, 2018 09:33

Xarn: Jun 26, 2015

Cybernetic Vermin posted:

if the thinking is to defer cleaning up objects for a long time to get a huge amount of work done: why not defer the entire gc if you have that kind of memory to spare?

Also known as the strategy for JVM benchmarks for a while.

# ? Oct 20, 2018 10:07

Cybernetic Vermin: Apr 18, 2005

it is clearly the best bet for throughput, so not a bad strategy. as mitnick noted above there are a lot of valid tradeoffs

# ? Oct 20, 2018 10:26

Soricidus: Oct 21, 2010; freedom-hating statist shill

Xarn posted:

Also known as the strategy for JVM benchmarks for a while.

they literally just introduced a new �null gc� option for this

# ? Oct 20, 2018 10:35

Sweeper: Nov 29, 2007; The Joe Buck of Posting; Dinosaur Gum

Notorious b.s.d. posted:

the tl;dr version: there are several tradeoffs among:

leaving garbage "alive" in the heap, wasting memory

"stopping the world" (pausing)

spending too much cpu time on gc (on multiple threads or one)

scaling to varying heap sizes -- the strategy that handles the first three tradeoffs well in a 500 MB heap almost certainly fails in a 2 TB heap

there is no free lunch in garbage collection, ever. every gc strategy falls down somewhere.

(there is also not a free lunch in avoiding garbage collection: malloc() and free() have extraordinarily unpleasant behaviors in corner cases. the C++ whackadoos who rave about "RAII" are just moving the problem into hairy profiling issues)

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?

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.

# ? Oct 20, 2018 12:28

Nomnom Cookie: Aug 30, 2009

then there�s the thing nginx does that I think is really cool: per-request arenas. bump pointer allocation and almost free deallocation

if I made a lang it would be event handling only and the two object lifetimes you get are forever and until then end of the handler

# ? Oct 20, 2018 16:11

MononcQc: May 29, 2007

fwiw that�s a trick for some Erlang code. Allocate enough memory for a short-lived process doing some work to never need a GC, and as the process dies, it gets reaped for free.

The risk of doing that with longer-lived processes and non-isolated memory is that you can really accelerate memory fragmentation.

# ? Oct 20, 2018 16:19

jeffery: Jan 1, 2013

oh interesting, tim's virus also granted him free unlimited sentinels to have sex with

# ? Oct 20, 2018 16:20

Carthag Tuek: Oct 15, 2005; Tider skal komme,
tider skal henrulle,
sl�gt skal f�lge sl�gters gang

jeffery posted:

oh interesting, tim's virus also granted him free unlimited sentinels to have sex with

you need to take your brain meds, friend

# ? Oct 20, 2018 17:27

Adbot: ADBOT LOVES YOU

# ? Jun 11, 2024 23:32

Notorious b.s.d.: Jan 25, 2003; by Reene

Soricidus posted:

they literally just introduced a new �null gc� option for this

that's been an option on the IBM JVM for many years

sadly i had good reason to use it at a past job

# ? Oct 20, 2018 17:34

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »