@enum types on a 64-bit system (v"0.4-")

[Douglas Bates]

It seems from the output of Julia fieldoffsets function that the size of a field declared to be a type generated by the @enum macro is 8 bytes.  Using offsetof in a C program shows the size of an enum field to be 4 bytes.  Is this intentional?  It means that you can't use unsafe_load of a C pointer to a struct to create a type instance if you have an @enum in the Julia type and an enum in the C struct.

[Douglas Bates]

I should have mentioned that this is using

julia> versioninfo()

Julia Version 0.4.0-dev+4893

Commit eb5da26* (2015-05-19 11:51 UTC)

Platform Info:

  System: Linux (x86_64-linux-gnu)

  CPU: AMD Athlon(tm) II X4 635 Processor

  WORD_SIZE: 64

  BLAS: libopenblas (NO_AFFINITY BARCELONA)

  LAPACK: libopenblas

  LIBM: libopenlibm

  LLVM: libLLVM-3.6.0

on an amd_64 Ubuntu 15.04 system.

[Douglas Bates]

Ah, I see that if I call the macro as

julia> @enum(foo,bar=Int32(0),baz,boz)

julia> sizeof(bar)

4

I get the desired size.

[Jacob Quinn]

You beat me to your own response :)

[Scott Jones]

That seems pretty crufty to me... always taking up 8 bytes for something that frequently could be stored in a byte, or have to play around like that in the definition, doesn't seem that good...

Maybe @enum should 1) by default, pick the smallest size possible to represent the values of the enum (Int8, UInt8, ... up to Int128, UInt128) (if they are all Integer values)

and 2) have syntax to specify the underlying type (in order to match external enumerations in C/C++ interfaces), something like: @enum(foo::UInt32, bar, baz, boz)

[ele...@gmail.com]

On Wednesday, May 20, 2015 at 10:11:20 PM UTC+10, Scott Jones wrote:

That seems pretty crufty to me... always taking up 8 bytes for something that frequently could be stored in a byte, or have to play around like that in the definition, doesn't seem that good...

Don't sweat it, a few years ago we did a survey of a large corpus of C++ code and found that allocation alignment requirements and alignment requirements of other structure members meant that more than 80% of Uint8 enums were actually taking up a full word (32 or 64 bits depending on the system).  Unless you have to map it to an existing C type layout it doesn't matter.

[Scott Jones]

You didn't look at any of my C/C++ code!

I am *very* careful about how I pack my structures, as much as possible no wasted bytes, every little bit is important when you've got 10s of thousands of processes... don't want a system thrashing!

Do you think my suggestion would be a bad thing for @enums to do in Julia?

[ele...@gmail.com]

On Wednesday, May 20, 2015 at 10:56:48 PM UTC+10, Scott Jones wrote:

You didn't look at any of my C/C++ code!

I am *very* careful about how I pack my structures, as much as possible no wasted bytes, every little bit is important when you've got 10s of thousands of processes... don't want a system thrashing!

Do you think my suggestion would be a bad thing for @enums to do in Julia?

No, because it does.

Reading the code, (since the 0.4 docs seem to still be missing) unless you manually specify the size by giving the first member of the enum a type (as shown in a previous post) then the @enum macro already makes the data type the smallest int that 1) fits the number of members, or 2) fits the values if any member is assigned a value.  Which is exactly what you suggested.

I wasn't trying to suggest this is bad, just that it often doesn't matter, "don't sweat what type you get".

My reply was related to the the original post which talked about using field offsets, which will show the amount of memory that it occupies *in the structure*, which is as I said usually rounds up to a word anyway, no matter what the enums type.

Its only obsessives like us who gather all the small fields together so they don't do that. :)

[Scott Jones]

Duh, silly me!  I'd thought from Douglas's message, that @enum was always using an Int or UInt...

and yes, I see you've realized I'm rather obsessive about little points of performance ;-)

(You should see the tricks I've played to stop cache-line ping-ponging!)

[John Myles White]

Please keep the personal chit-chat to a minimum on this mailing list. People's time is Julia's most valuable resource.

 -- John