Re: [GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
-+--
Reporter:  nomeata   |Owner: 
Type:  feature request   |   Status:  closed 
Priority:  normal|Milestone:  6.12.1 
   Component:  Compiler  |  Version:  6.10.1 
Severity:  normal|   Resolution:  fixed  
Keywords:|   Difficulty:  Unknown
Testcase:|   Os:  Linux  
Architecture:  Unknown/Multiple  |  
-+--
Changes (by igloo):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 I've made Int's get serialized as Int64, and opened #3379 for making GHC
 use the standard binary package.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
-+--
Reporter:  nomeata   |Owner: 
Type:  feature request   |   Status:  new
Priority:  normal|Milestone:  6.12.1 
   Component:  Compiler  |  Version:  6.10.1 
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
Testcase:|   Os:  Linux  
Architecture:  Unknown/Multiple  |  
-+--
Changes (by igloo):

  * milestone:  => 6.12.1

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
-+--
Reporter:  nomeata   |Owner: 
Type:  feature request   |   Status:  new
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.10.1 
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
Testcase:|   Os:  Linux  
Architecture:  Unknown/Multiple  |  
-+--
Comment (by simonmar):

 Replying to [comment:10 duncan]:
 > Replying to [comment:9 simonmar]:
 > > I've been lead to believe that the performance of `Data.Binary` isn't
 as good as our `Binary` library.  I don't have figures to back that up,
 but performance of reading interface files is pretty important to us.  So
 I've been holding off on switching until `Data.Binary` has had some
 tuning.
 >
 > There was a regression in the performance of `Data.Binary` from ghc-6.8
 to 6.10 which is perhaps what you're thinking of. Prior to that it was
 several times faster (10x at the time of the binary-0.4 release) than
 `NewBinary` which I believe was basically ghc's binary implementation
 extracted into a standalone library. Don looked at the performance
 regression so is best placed to say if the latest release brings
 performance back up to what it was with 6.8.

 `NewBinary` is somewhat slower than GHC's binary library, IIRC, because it
 added support for using a more compact serialisation format based on bits
 rather than bytes.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
-+--
Reporter:  nomeata   |Owner: 
Type:  feature request   |   Status:  new
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.10.1 
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
Testcase:|   Os:  Linux  
Architecture:  Unknown/Multiple  |  
-+--
Comment (by duncan):

 Replying to [comment:9 simonmar]:
 > Replying to [comment:7 igloo]:
 >
 > > Is there a reason for GHC not to use `Data.Binary` too? The only
 reason I can think of would be to avoid the extra dependency, but if
 haddock uses it then the GHC build depends on it anyway. Personally, I
 don't think it's a strong enough reason to maintain our own Binary anyway.
 >
 > I've been lead to believe that the performance of `Data.Binary` isn't as
 good as our `Binary` library.  I don't have figures to back that up, but
 performance of reading interface files is pretty important to us.  So I've
 been holding off on switching until `Data.Binary` has had some tuning.

 There was a regression in the performance of `Data.Binary` from ghc-6.8 to
 6.10 which is perhaps what you're thinking of. Prior to that it was
 several times faster (10x at the time of the binary-0.4 release) than
 `NewBinary` which I believe was basically ghc's binary implementation
 extracted into a standalone library. Don looked at the performance
 regression so is best placed to say if the latest release brings
 performance back up to what it was with 6.8.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
-+--
Reporter:  nomeata   |Owner: 
Type:  feature request   |   Status:  new
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.10.1 
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
Testcase:|   Os:  Linux  
Architecture:  Unknown/Multiple  |  
-+--
Comment (by simonmar):

 Replying to [comment:7 igloo]:

 > Is there a reason for GHC not to use `Data.Binary` too? The only reason
 I can think of would be to avoid the extra dependency, but if haddock uses
 it then the GHC build depends on it anyway. Personally, I don't think it's
 a strong enough reason to maintain our own Binary anyway.

 I've been lead to believe that the performance of `Data.Binary` isn't as
 good as our `Binary` library.  I don't have figures to back that up, but
 performance of reading interface files is pretty important to us.  So I've
 been holding off on switching until `Data.Binary` has had some tuning.

 > So if GHC switches to `Data.Binary`, then all haddock needs to do is
 wait.

 Haddock just needs a binary serialisation library, there's no reason it
 has to use the same one as GHC.  And even if GHC switched, Haddock would
 have to be updated to use `Data.Binary` too.

 > In the mean time (i.e. for 6.10.2), we can fix the immediate problem by
 changing the `Int` instance to to serialise as `Int32` or `Int64`
 consistently.

 I think that's a bad idea.  If we use `Int64` then interface files get
 bigger on 32-bit machines; if we use `Int32` then we introduce new failure
 modes.  We could use some hybrid encoding I suppose, but I'd rather
 Haddock was just decoupled from GHC's binary library altogether.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
-+--
Reporter:  nomeata   |Owner: 
Type:  feature request   |   Status:  new
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.10.1 
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
Testcase:|   Os:  Linux  
Architecture:  Unknown/Multiple  |  
-+--
Comment (by waern):

 I added a Haddock ticket for this:

   http://trac.haskell.org/haddock/ticket/96

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
-+--
Reporter:  nomeata   |Owner: 
Type:  feature request   |   Status:  new
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.10.1 
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
Testcase:|   Os:  Linux  
Architecture:  Unknown/Multiple  |  
-+--
Comment (by igloo):

 Replying to [comment:6 simonmar]:
 > The problem here is not that GHC's Binary library has an instance for
 `Int`, it is that Haddock uses GHC's `Binary` library at all.  GHC's
 `Binary` library is for serialising interface files, and since interface
 files can be platform-specific it doesn't matter that we have a platform-
 specific instance for `Int`.
 >
 > I think Haddock should either use a local copy of Binary with a
 platform-independent serialisation format (like it used to! :-) or it
 should use `Data.Binary`.  The latter adds a new dependency to GHC, but in
 the long run that's not a disaster.  For a quick fix, the former solution
 will do fine.

 Is there a reason for GHC not to use `Data.Binary` too? The only reason I
 can think of would be to avoid the extra dependency, but if haddock uses
 it then the GHC build depends on it anyway. Personally, I don't think it's
 a strong enough reason to maintain our own Binary anyway.

 So if GHC switches to `Data.Binary`, then all haddock needs to do is wait.
 In the mean time (i.e. for 6.10.2), we can fix the immediate problem by
 changing the `Int` instance to to serialise as `Int32` or `Int64`
 consistently.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
-+--
Reporter:  nomeata   |Owner: 
Type:  feature request   |   Status:  new
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.10.1 
Severity:  normal|   Resolution: 
Keywords:|   Difficulty:  Unknown
Testcase:|   Os:  Linux  
Architecture:  Unknown/Multiple  |  
-+--
Changes (by simonmar):

  * difficulty:  => Unknown

Comment:

 The problem here is not that GHC's Binary library has an instance for
 `Int`, it is that Haddock uses GHC's `Binary` library at all.  GHC's
 `Binary` library is for serialising interface files, and since interface
 files can be platform-specific it doesn't matter that we have a platform-
 specific instance for `Int`.

 I think Haddock should either use a local copy of Binary with a platform-
 independent serialisation format (like it used to! :-) or it should use
 `Data.Binary`.  The latter adds a new dependency to GHC, but in the long
 run that's not a disaster.  For a quick fix, the former solution will do
 fine.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
-+--
 Reporter:  nomeata  |  Owner:  
 Type:  feature request  | Status:  new 
 Priority:  normal   |  Milestone:  
Component:  Compiler |Version:  6.10.1  
 Severity:  normal   | Resolution:  
 Keywords:   |   Testcase:  
   Os:  Linux|   Architecture:  Unknown/Multiple
-+--
Comment (by kaol):

 Here's another thought regarding this. Let's remove the whole {{{instance
 Binary Int}}}. That'd make anyone using Binary to have to choose between
 using Int32 and Int64. Having an Int instance is just asking for errors
 when moving data between 32 and 64 bit architectures, at some point. It
 may be inconvenient for people using Binary, but I assume that it's meant
 to be a low level interface, anyway.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
-+--
 Reporter:  nomeata  |  Owner:  
 Type:  feature request  | Status:  new 
 Priority:  normal   |  Milestone:  
Component:  Compiler |Version:  6.10.1  
 Severity:  normal   | Resolution:  
 Keywords:   |   Testcase:  
   Os:  Linux|   Architecture:  Unknown/Multiple
-+--
Comment (by dons):

 N.B. this isnt' referring to Data.Binary, which serialises as:

 {{{
 -- Ints are are written as Int64s, that is, 8 bytes in big endian format
 instance Binary Int where
 put i   = put (fromIntegral i :: Int64)
 get = liftM fromIntegral (get :: Get Int64)
 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
-+--
 Reporter:  nomeata  |  Owner:  
 Type:  feature request  | Status:  new 
 Priority:  normal   |  Milestone:  
Component:  Compiler |Version:  6.10.1  
 Severity:  normal   | Resolution:  
 Keywords:   |   Testcase:  
   Os:  Linux|   Architecture:  Unknown/Multiple
-+--
Comment (by kaol):

 I'd use this, to add some error checking.

 {{{
 instance Binary Int where
 put_ bh i = if i < (minBound::Int32) || i > (maxBound::Int32)
 then error "Binary.instance Binary Int: Int out of bounds
 for Int32"
 else put_ bh (fromIntegral i :: Int32)
 get  bh = do
 x <- get bh
 return $! (fromIntegral (x :: Int32))
 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
-+--
 Reporter:  nomeata  |  Owner:  
 Type:  feature request  | Status:  new 
 Priority:  normal   |  Milestone:  
Component:  Compiler |Version:  6.10.1  
 Severity:  normal   | Resolution:  
 Keywords:   |   Testcase:  
   Os:  Linux|   Architecture:  Unknown/Multiple
-+--
Comment (by nomeata):

 Just to be clear: If this code in Binary.hs:
 {{{
 instance Binary Int where
 #if SIZEOF_HSINT == 4
 put_ bh i = put_ bh (fromIntegral i :: Int32)
 get  bh = do
 x <- get bh
 return $! (fromIntegral (x :: Int32))
 #elif SIZEOF_HSINT == 8
 put_ bh i = put_ bh (fromIntegral i :: Int64)
 get  bh = do
 x <- get bh
 return $! (fromIntegral (x :: Int64))
 #else
 #error "unsupported sizeof(HsInt)"
 #endif
 --getF bh   = getBitsF bh 32
 }}}

 could be changed to this code (Int64 or Int32, but choose one)
 {{{
 instance Binary Int where
 put_ bh i = put_ bh (fromIntegral i :: Int32)
 get  bh = do
 x <- get bh
 return $! (fromIntegral (x :: Int32))
 }}}

 then the Binary serialization would be arch-independent again. (At least,
 AFAICT)

 Is there any reason not to do so?

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
-+--
 Reporter:  nomeata  |  Owner:  
 Type:  feature request  | Status:  new 
 Priority:  normal   |  Milestone:  
Component:  Compiler |Version:  6.10.1  
 Severity:  normal   | Resolution:  
 Keywords:   |   Testcase:  
   Os:  Linux|   Architecture:  Unknown/Multiple
-+--
Comment (by nomeata):

 I think it affects (at least):
  * Int, as the basic culprit. Change the Binary instance of Int, fixes all
 the following cases.
  * FastString, for the length variable
  * PackageId, ModuleName, as they are FastString newtypes (so either the
 FastString instance has to be changed, or copied and “arch-independized”
 for PackageId, ModuleName
  * OccName, builds on NameSpace and FastString

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #3041: Arch independent binary representations

[GHC]

#3041: Arch independent binary representations
+---
Reporter:  nomeata  |  Owner:  
Type:  feature request  | Status:  new 
Priority:  normal   |  Component:  Compiler
 Version:  6.10.1   |   Severity:  normal  
Keywords:   |   Testcase:  
  Os:  Linux|   Architecture:  Unknown/Multiple
+---
 Hi,

 when packaging ghc6.10 for Debian, we stumbled over a rather large
 annoyance: Haddock’s .haddock files are not architecture independent any
 more. It uses Binary instances to serialize it’s data, and for Int, the
 size depends on the architecture it is running. As otherwise the .haddock
 files should not be arch independent, it would make life for the ghc6
 maintainer easier if this can be changed.

 I started to fix haddock there, but it uses the Binary instance for some
 of ghc6 internal structures (Name at least, maybe more), which also
 serialize Int’s without specifying the size.

 Would it be accepted to change the Binary instances for (at least) these
 data types to convert all Int’s to Int32’s or Int64’s before
 serialization? What would be broken by such a change?

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs