Johan Tibell | 14 Dec 21:53 2012
Picon

How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient

Hi,

I've been tracking down a few (unrelated) performance bugs related to
conversions between primitive types. What these issues had in common
is that some rule failed to fire and the conversion went via Integer,
killing performance. How do we best write a test that make sure that
fromIntegral conversions between these types don't regress? Is it
possible to test the output of the simplifier or do we have to do
something less direct, like writing a loop that does such conversions
and make sure that the allocation stay low?

-- Johan
Ian Lynagh | 14 Dec 22:18 2012

Re: How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient

On Fri, Dec 14, 2012 at 12:53:36PM -0800, Johan Tibell wrote:
> 
> I've been tracking down a few (unrelated) performance bugs related to
> conversions between primitive types. What these issues had in common
> is that some rule failed to fire and the conversion went via Integer,
> killing performance. How do we best write a test that make sure that
> fromIntegral conversions between these types don't regress? Is it
> possible to test the output of the simplifier or do we have to do
> something less direct, like writing a loop that does such conversions
> and make sure that the allocation stay low?

We have some tests looking at the -ddumjp-simpl output, e.g.
integerConstantFolding. I'm not sure if we have one for type conversions
OTTOMH.

Thanks
Ian
Carter Schonwald | 14 Dec 22:34 2012
Picon

Re: How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient

A related question I have is that I've some code that will map the singleton Nats to Ints, and last time I looked into this/ had a chat on the ghc-users list, it sounded like sometimes having Integer values constructed in between are unavoidable.  Is that still the case with post 7.6.1 ghc? (And or, how might I be able to help?)

On Friday, December 14, 2012, Ian Lynagh wrote:

On Fri, Dec 14, 2012 at 12:53:36PM -0800, Johan Tibell wrote:
>
> I've been tracking down a few (unrelated) performance bugs related to
> conversions between primitive types. What these issues had in common
> is that some rule failed to fire and the conversion went via Integer,
> killing performance. How do we best write a test that make sure that
> fromIntegral conversions between these types don't regress? Is it
> possible to test the output of the simplifier or do we have to do
> something less direct, like writing a loop that does such conversions
> and make sure that the allocation stay low?

We have some tests looking at the -ddumjp-simpl output, e.g.
integerConstantFolding. I'm not sure if we have one for type conversions
OTTOMH.


Thanks
Ian


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Ian Lynagh | 14 Dec 22:47 2012
Picon

Re: How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient


Hi Carter,

On Fri, Dec 14, 2012 at 04:34:29PM -0500, Carter Schonwald wrote:
> A related question I have is that I've some code that will map the
> singleton Nats to Ints, and last time I looked into this/ had a chat on the
> ghc-users list, it sounded like sometimes having Integer values constructed
> in between are unavoidable.  Is that still the case with post 7.6.1 ghc?
> (And or, how might I be able to help?)

I don't know what a singleton Nat is, but if you mean Word then that's
what Johan's been working on.

Thanks
Ian
Sean Leather | 14 Dec 23:12 2012
Picon

Re: How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient

On Fri, Dec 14, 2012 at 10:47 PM, Ian Lynagh wrote:

On Fri, Dec 14, 2012 at 04:34:29PM -0500, Carter Schonwald wrote:
> A related question I have is that I've some code that will map the
> singleton Nats to Ints, and last time I looked into this/ had a chat on the
> ghc-users list, it sounded like sometimes having Integer values constructed
> in between are unavoidable.  Is that still the case with post 7.6.1 ghc?
> (And or, how might I be able to help?)

I don't know what a singleton Nat is, but if you mean Word then that's
what Johan's been working on.

I'm guessing Carter means Sing Nat:

Regards,
Sean
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Carter Schonwald | 14 Dec 23:30 2012
Picon

Re: How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient

Yes, thanks Sean for helping clarify! 

yes, The TypeLits Nat

I had a discussion on the list with Iavor and others a few months back 

and there were some examples and dialogue beyond that with Iavor and SPJ, but it was off list. 

point being: for Word or Int sized instances of Nat singleton, theres a number of interesting ways having that information used to statically specialize a numerical computation with some constants is handy, and last time I asked it sounded like the story for this wasn't fully worked out.

I hope I'm explaining clearly, if not I'll be happy to try to elaborate further

-Carter




On Fri, Dec 14, 2012 at 5:12 PM, Sean Leather <leather <at> cs.uu.nl> wrote:
On Fri, Dec 14, 2012 at 10:47 PM, Ian Lynagh wrote:

On Fri, Dec 14, 2012 at 04:34:29PM -0500, Carter Schonwald wrote:
> A related question I have is that I've some code that will map the
> singleton Nats to Ints, and last time I looked into this/ had a chat on the
> ghc-users list, it sounded like sometimes having Integer values constructed
> in between are unavoidable.  Is that still the case with post 7.6.1 ghc?
> (And or, how might I be able to help?)

I don't know what a singleton Nat is, but if you mean Word then that's
what Johan's been working on.

I'm guessing Carter means Sing Nat:

Regards,
Sean

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Simon Peyton-Jones | 17 Dec 10:49 2012
Picon

RE: How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient

Best thing to do is to produce a concrete example, showing the code you think is sub-optimal

 

Simon

 

From: glasgow-haskell-users-bounces <at> haskell.org [mailto:glasgow-haskell-users-bounces <at> haskell.org] On Behalf Of Sean Leather
Sent: 14 December 2012 22:13
To: GHC Users List; Ian Lynagh
Subject: Re: How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient

 

On Fri, Dec 14, 2012 at 10:47 PM, Ian Lynagh wrote:

On Fri, Dec 14, 2012 at 04:34:29PM -0500, Carter Schonwald wrote:
> A related question I have is that I've some code that will map the
> singleton Nats to Ints, and last time I looked into this/ had a chat on the
> ghc-users list, it sounded like sometimes having Integer values constructed
> in between are unavoidable.  Is that still the case with post 7.6.1 ghc?
> (And or, how might I be able to help?)

I don't know what a singleton Nat is, but if you mean Word then that's
what Johan's been working on.

 

I'm guessing Carter means Sing Nat:

 

Regards,

Sean

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
David Terei | 15 Dec 02:29 2012
Picon

Re: How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient

I believe the testsuite now has support for inspecting assembly
output. Not sure if that would be best for your use case, but
something to consider.

On 14 December 2012 12:53, Johan Tibell <johan.tibell <at> gmail.com> wrote:
> Hi,
>
> I've been tracking down a few (unrelated) performance bugs related to
> conversions between primitive types. What these issues had in common
> is that some rule failed to fire and the conversion went via Integer,
> killing performance. How do we best write a test that make sure that
> fromIntegral conversions between these types don't regress? Is it
> possible to test the output of the simplifier or do we have to do
> something less direct, like writing a loop that does such conversions
> and make sure that the allocation stay low?
>
> -- Johan
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users <at> haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Simon Peyton-Jones | 17 Dec 10:46 2012
Picon

RE: How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient

The sure-fire way is to make a loop that doesn't allocate if the rules fire; after all that's the ultimate
goal.  Then you can put it in tests/perf/should_run.

doing -ddump-simpl and greping for stuff that should/should-not be there is another alternative we use in places.

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces <at> haskell.org [mailto:glasgow-haskell-
| users-bounces <at> haskell.org] On Behalf Of Johan Tibell
| Sent: 14 December 2012 20:54
| To: glasgow-haskell-users
| Subject: How do we best make sure {Int,Word,Float,Double} to
| {Int,Word,Float,Double} conversions stay efficient
| 
| Hi,
| 
| I've been tracking down a few (unrelated) performance bugs related to
| conversions between primitive types. What these issues had in common is
| that some rule failed to fire and the conversion went via Integer,
| killing performance. How do we best write a test that make sure that
| fromIntegral conversions between these types don't regress? Is it
| possible to test the output of the simplifier or do we have to do
| something less direct, like writing a loop that does such conversions
| and make sure that the allocation stay low?
| 
| -- Johan
| 
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users <at> haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Gmane