On Fri, Aug 19, 2016 at 10:07 AM, Yichao Yu <yyc1...@gmail.com> wrote:
> > > On Fri, Aug 19, 2016 at 10:01 PM, Erik Schnetter <schnet...@gmail.com> > wrote: > >> On Fri, Aug 19, 2016 at 9:53 AM, Yichao Yu <yyc1...@gmail.com> wrote: >> >>> >>> On Fri, Aug 19, 2016 at 9:01 PM, Oliver Schulz < >>> oliver.sch...@tu-dortmund.de> wrote: >>> >>>> Hi Eric, >>>> >>>> nice - this is exactly what I meant. I wonder if Julia Symbols >>>> themselves could become like this in the future. >>>> >>> >>> As jameson said already, isbits or not is irrelevant here and we are >>> working towards making non isbits type inlinable. >>> >>> The ValueSymbol type is also not a true isbits type, you can't save it >>> to sysimg or use it with mmap array for example (well, you can, but you >>> won't get the answer you want) >>> >> >> Okay, call it `pointerfree` then. >> > > Well, the point is that it doesn't have all the necessary probably assumed > by other part of the system. `isbits` is an acronym of `pointerfree`. > Can I mmap regular symbols? What ensures that the symbols' values are contained in the mmapped region? What ensures that mmapped symbols are unique with respect to local symbols? Saving in a system image is an operation for experts; there are good solutions for ensuring symbols are stored and loaded properly, such as e.g. serializing them. -erik 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 <yyc1...@gmail.com >>>>> <mailto:yyc1...@gmail.com>> wrote: >>>>> >>>>> >>>>> >>>>> On Wed, Aug 17, 2016 at 10:19 PM, Oliver Schulz >>>>> <oliver.sch...@tu-dortmund.de <mailto:oliver.sch...@tu-dortmund.de >>>>> >> >>>>> >>>>> 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) >>>>> >>>>> 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 <schn...@gmail.com> >>>>> http://www.perimeterinstitute.ca/personal/eschnetter/ >>>>> <http://www.perimeterinstitute.ca/personal/eschnetter/ >>>>> > >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Erik Schnetter <schnet...@gmail.com <mailto:schnet...@gmail.com>> >>>>> http://www.perimeterinstitute.ca/personal/eschnetter/ >>>>> >>>> >>>> >>> >> >> >> -- >> Erik Schnetter <schnet...@gmail.com> http://www.perimeterinstitute. >> ca/personal/eschnetter/ >> > > -- Erik Schnetter <schnet...@gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/
