Thanks for the explanation, Yichao!
On Wednesday, August 17, 2016 at 4:33:43 PM UTC+2, Yichao Yu wrote: > > > > On Wed, Aug 17, 2016 at 10:19 PM, Oliver Schulz <oliver...@tu-dortmund.de > <javascript:>> 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 <cedric...@gmail.com> >>>> 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 < >>>>> oliver...@tu-dortmund.de> wrote: >>>>> >>>>>> Hello Andreas, >>>>>> >>>>>> consider iterating over a Dict{Symbol,Int64}: >>>>>> >>>>>> d = Dict(:foo => 42, :bar => 77) >>>>>> for x in d 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 <schn...@gmail.com> >>>> http://www.perimeterinstitute.ca/personal/eschnetter/ >>>> >>> >>> >