On Fri, Aug 19, 2016 at 9:53 PM, Erik Schnetter <[email protected]> wrote:
> If Julia symbols are never garbage collected, then they could be directly > implemented as a (bitstype) C pointer to a malloc'd region. There's no need > to involve Julia's memory allocator or garbage collector, or tell the > garbage collector about variables holding symbols. > Loading symbols never involve the GC/allocator. OTOH, it might when the symbol becomes a isbits. > > -erik > > On Fri, Aug 19, 2016 at 9:01 AM, Oliver Schulz < > [email protected]> wrote: > >> Hi Eric, >> >> nice - this is exactly what I meant. I wonder if Julia Symbols themselves >> could become like this in the future. >> >> >> Cheers, >> >> Oliver >> >> >> On 17.08.2016 18:44, Erik Schnetter wrote: >> >>> See <https://github.com/eschnett/ValueSymbols.jl> for what I had in >>> mind. >>> >>> -erik >>> >>> On Wed, Aug 17, 2016 at 10:32 AM, Yichao Yu <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> On Wed, Aug 17, 2016 at 10:19 PM, Oliver Schulz >>> <[email protected] <mailto:[email protected]>> >>> wrote: >>> >>> Hi Yichao >>> >>> I get that - I was just curious why (and I guess there's likely >>> a very good reason for it). My intuition would be that a >>> non-GCed interned string type could be represented by a bitstype >>> (i.e. a pointer or index to the string table). So I was >>> surprised that Symbol is an object reference and wanted to >>> understand this a bit better. >>> >>> >>> It's a pointer to managed memory with tag that's all what's needed >>> for it to be a !pointerfree type. There are way more things that we >>> don't GC and it has nothing to do with whether it's a isbits type or >>> not. >>> >>> >>> >>> >>> Cheers, >>> >>> Oliver >>> >>> >>> On Wednesday, August 17, 2016 at 3:35:41 PM UTC+2, Yichao Yu >>> wrote: >>> >>> >>> > PS: Yes, symbols in Julia should be bitstypes. >>> >>> No, it's a object reference and isn't a `isbits()` type. >>> >>> >>> >>> On Wed, Aug 17, 2016 at 8:26 AM, Cedric St-Jean >>> <[email protected]> wrote: >>> >>> Good points. >>> >>> Given that symbols have a name which is a string, I >>> don't see how they could be a bits-type unless they >>> just became numbers to index into a global array >>> somewhere...... i.e. a pointer. Stack-allocating >>> non-bits-type immutables is on the roadmap to 1.0, >>> so that should solve your problems. >>> >>> Maybe you can solve the CategorizedPoint problem by >>> using an @enum. >>> >>> On Wed, Aug 17, 2016 at 6:48 AM, Oliver Schulz >>> <[email protected]> wrote: >>> >>> Hello Andreas, >>> >>> consider iterating over a Dict{Symbol,Int64}: >>> >>> | >>> d =Dict(:foo =>42,:bar =>77) >>> forx ind println("$(typeof(x)), $(isbits(x))")end >>> | >>> >>> >>> During iteration, a lot of stack allocated >>> "Pair{Symbol,Int64}" objects are created. That >>> is very bad for performance. >>> >>> | >>> immutable CategorizedPoint >>> x::Float64 >>> y::Float64 >>> category::Symbol >>> end >>> | >>> >>> >>> Also, consider a (hypothetical) data type for >>> categorized points (with a finite number of >>> categories - but extensible, so that Symbol is a >>> better fit than using an enum): >>> >>> immutable CategorizedPoint >>> x::Float64 >>> y::Float64 >>> category::Symbol >>> end >>> >>> I would definitely want this to be a bits-type, >>> and not have every instance heap-allocated. >>> >>> >>> Cheers, >>> >>> Oliver >>> >>> >>> On Wednesday, August 17, 2016 at 11:44:13 AM >>> UTC+2, Andreas Lobinger wrote: >>> >>> Hello colleague, >>> >>> On Wednesday, August 17, 2016 at 11:12:51 AM >>> UTC+2, Oliver Schulz wrote: >>> >>> Sure - I was assuming that as Symbol >>> (as an interned string) is basically >>> just a pointer. So comparisons are O(1), >>> etc. What I'd like to understand is, why >>> can't it be a bitstype? Currently, it's >>> not, so Symbol cannot be used in a >>> lightweight (i.e. stack-allocated) >>> immutable type. I assume there's a good >>> reason for it, I just want to understand >>> why. >>> >>> >>> Could you make an example how you would like >>> to use Symbol in lightweight types? >>> >>> >>> >>> >>> >>> -- >>> Erik Schnetter <[email protected]> >>> http://www.perimeterinstitute.ca/personal/eschnetter/ >>> <http://www.perimeterinstitute.ca/personal/eschnetter/> >>> >>> >>> >>> >>> >>> >>> -- >>> Erik Schnetter <[email protected] <mailto:[email protected]>> >>> http://www.perimeterinstitute.ca/personal/eschnetter/ >>> >> >> > > > -- > Erik Schnetter <[email protected]> http://www.perimeterinstitute. > ca/personal/eschnetter/ >
