Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
#6084: Add stg_ap_pnnv and related call patterns -+-- Reporter: SimonMeier| Owner: simonmar Type: feature request | Status: new Priority: normal| Milestone: 7.8.1 Component: Runtime System| Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by simonmar): Replying to [comment:3 SimonMeier]: The change only improves unknown calls with unboxed arguments and a final void argument. Attoparsec does not profit, as it does not require side-effects. The binary builder could profit, but in its current form it would additipnally require the stg_ap_pnnnv and stg_ap_nnnv call patterns. I don't understand why side-effects is an issue, and why you say that Attoparsec would not benefit. Could you elaborate? Also I don't understand why Builder would benefit, because the unknown function in this case has type `(Buffer - IO L.ByteString)`, which is just the `stg_ap_pv` pattern, which we already have (it is a higher-order function, so the `Buffer` argument won't be unboxed). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6084#comment:4 GHC http://www.haskell.org/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] #6084: Add stg_ap_pnnv and related call patterns
#6084: Add stg_ap_pnnv and related call patterns
-+--
Reporter: SimonMeier| Owner: simonmar
Type: feature request | Status: new
Priority: normal| Milestone: 7.8.1
Component: Runtime System| Version: 7.4.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by SimonMeier):
Replying to [comment:4 simonmar]:
Replying to [comment:3 SimonMeier]:
The change only improves unknown calls with unboxed arguments and a
final void argument. Attoparsec does not profit, as it does not require
side-effects. The binary builder could profit, but in its current form it
would additipnally require the stg_ap_pnnnv and stg_ap_nnnv call patterns.
I don't understand why side-effects is an issue, and why you say that
Attoparsec would not benefit. Could you elaborate?
Also I don't understand why Builder would benefit, because the unknown
function in this case has type `(Buffer - IO L.ByteString)`, which is
just the `stg_ap_pv` pattern, which we already have (it is a higher-order
function, so the `Buffer` argument won't be unboxed)
The unboxing has to be done manually using `Addr#` arguments, as shown for
the new bytestring builder in the original description of this ticket. The
existing binary builder this would entail the use of functions of type
{{{
type BuildStep = ForeignPtr - Int# - Int# - Int# - IO L.ByteString
type Builder = BuildStep - BuildStep
}}}
which would actually result in a `stg_ap_ppnnnv` call pattern.
On a high level, this ticket aims to provide support for unknown calls
with multiple unboxed arguments and a final void argument. This allows to
eliminate unnecessary allocations of boxing structures like the `Buffer`
in the binary builder and `Ptr Word8` in the new bytestring builder. In
the context of bytestring builders, this elimination is relevant because
there are cases where we require as much as one unknown function call per
word written to the output buffer.
Note that side-effects is not directly an issue. The sequencing of side-
effects via the final `void` argument is however, as it changes the call
pattern.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6084#comment:5
GHC http://www.haskell.org/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] #6084: Add stg_ap_pnnv and related call patterns
#6084: Add stg_ap_pnnv and related call patterns -+-- Reporter: SimonMeier| Owner: simonmar Type: feature request | Status: new Priority: normal| Milestone: 7.8.1 Component: Runtime System| Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Comment(by SimonMeier): @igloo: I have implemented the unboxed continuation calls in the past and I was astonished that they were slower than the boxed versions. I didn't know enough about the RTS at that time to understand whats going on. Once I read the eval/apply paper and the corresponding GHC sources the slowdown was however no longer surprising. Currently, unknown calls to IO functions with unboxed arguments are expensive because the 'apply' is executed in a one by one fashion. This feature request would change that. The change only improves unknown calls with unboxed arguments and a final void argument. Attoparsec does not profit, as it does not require side- effects. The binary builder could profit, but in its current form it would additipnally require the stg_ap_pnnnv and stg_ap_nnnv call patterns. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6084#comment:3 GHC http://www.haskell.org/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] #6084: Add stg_ap_pnnv and related call patterns
#6084: Add stg_ap_pnnv and related call patterns -+-- Reporter: SimonMeier| Owner: simonmar Type: feature request | Status: new Priority: normal| Milestone: 7.8.1 Component: Runtime System| Version: 7.4.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * owner: = simonmar * difficulty: = Unknown * component: Compiler = Runtime System * milestone: = 7.8.1 Comment: Thanks for the suggestion. If I follow correctly, you haven't actually benchmarked with the extra call patterns, but you believe that the lack of them is responsible for the slowdown? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6084#comment:1 GHC http://www.haskell.org/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] #6084: Add stg_ap_pnnv and related call patterns
#6084: Add stg_ap_pnnv and related call patterns
-+--
Reporter: SimonMeier| Owner: simonmar
Type: feature request | Status: new
Priority: normal| Milestone: 7.8.1
Component: Runtime System| Version: 7.4.1
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Comment(by tibbe):
I don't understand this issue well enough to comment on details, but if
it's true that continuation heavy code is helped by this change, should we
also consider covering the call pattern of binary:
{{{
newtype Builder = Builder {
runBuilder :: (Buffer - IO L.ByteString)
- Buffer
- IO L.ByteString
data Buffer = Buffer {-# UNPACK #-} !(ForeignPtr Word8)
{-# UNPACK #-} !Int-- offset
{-# UNPACK #-} !Int-- used bytes
{-# UNPACK #-} !Int-- length left
}
}}}
and attoparsec:
{{{
newtype Parser t a = Parser {
runParser :: forall r. Input t - Added t - More
- Failure t r
- Success t a r
- IResult t r
}
newtype Input t = I {unI :: t}
newtype Added t = A {unA :: t}
type Failure t r = Input t - Added t - More - [String] - String
- IResult t r
type Success t a r = Input t - Added t - More - a - IResult t r
data More = Complete | Incomplete
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/6084#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
