Question on performance/style issue

Question on performance/style issue

[Alessandro Baretta]

I am very fond of the following "duality" operator.

let (++) x f = f x

I use to write complex computations legibly: instead of
 > h(g(f(x)))
I write
 > x ++ f ++ g ++ h

What is the impact of the this programming style on execution performance?

Alex

-- 
*********************************************************************

Ing. Alessandro Baretta

Studio Baretta
http://studio.baretta.com/

Consulenza Tecnologica e Ingegneria Industriale
Technological Consulting and Industrial Engineering

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Re: [Caml-list] Question on performance/style issue

[Anil Madhavapeddy]

On Fri, Feb 24, 2006 at 04:52:41PM +0100, Alessandro Baretta wrote:
> I am very fond of the following "duality" operator.
> 
> let (++) x f = f x
> 
> I use to write complex computations legibly: instead of
> > h(g(f(x)))
> I write
> > x ++ f ++ g ++ h
> 
> What is the impact of the this programming style on execution performance?

>From a GC point of view, this is better than the alternative of
splitting up the calls into separate let bindings.  It's used in
the OCaml sources to make some long call-chains look nicer.


To reference the original post...
http://caml.inria.fr/pub/ml-archives/caml-list/2003/09/825011113899cde2b1b96cf7fc7a0f7b.en.html

-- 
Anil Madhavapeddy                                 http://anil.recoil.org
University of Cambridge                          http://www.cl.cam.ac.uk

Re: [Caml-list] Question on performance/style issue

[Alessandro Baretta]

Anil Madhavapeddy wrote:
>>>x ++ f ++ g ++ h
>>
>>What is the impact of the this programming style on execution performance?
> 
> 
>>From a GC point of view, this is better than the alternative of
> splitting up the calls into separate let bindings.  It's used in
> the OCaml sources to make some long call-chains look nicer.

Ah, yes, it makes one's code dense and legible at once. What I'm asking is 
whether the call to (++) manages to get compiled away--that is, reduced to its 
definition--or if I pay for the additional jump every time. In this latter case 
I might have to renounce the (++) operator in inner loops where I need to 
squeeze out every last bit of performance.

Alex

-- 
*********************************************************************

Ing. Alessandro Baretta

Studio Baretta
http://studio.baretta.com/

Consulenza Tecnologica e Ingegneria Industriale
Technological Consulting and Industrial Engineering

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Re: [Caml-list] Question on performance/style issue

[Andrej Bauer]

On Friday 24 February 2006 20:25, Alessandro Baretta wrote:
> Anil Madhavapeddy wrote:
> >>>x ++ f ++ g ++ h
> >>
> >>What is the impact of the this programming style on execution
> >> performance?

1. It should be easy enough to extend the syntax so that you don't have to 
worry about it getting compiled away.

2. Mathematica uses notation x // f. Why not use the same? Many people will 
misunderstand ++ as something coming from C.

Andrej

Re: Question on performance/style issue

[David M. Cooke]

Andrej Bauer <Andrej.Bauer@andrej.com> writes:

> On Friday 24 February 2006 20:25, Alessandro Baretta wrote:
>> Anil Madhavapeddy wrote:
>> >>>x ++ f ++ g ++ h
>> >>
>> >>What is the impact of the this programming style on execution
>> >> performance?
>
> 1. It should be easy enough to extend the syntax so that you don't have to 
> worry about it getting compiled away.
>
> 2. Mathematica uses notation x // f. Why not use the same? Many people will 
> misunderstand ++ as something coming from C.

Those of use who don't use Mathematica will misunderstand that as a
comment (from C++), or an integer divide (Python), or ...?

:-)

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)physics(dot)mcmaster(dot)ca

Re: [Caml-list] Re: Question on performance/style issue

[David Brown]

On Mon, Feb 27, 2006 at 05:37:37PM -0500, David M. Cooke wrote:
> Andrej Bauer <Andrej.Bauer@andrej.com> writes:
> 
> > On Friday 24 February 2006 20:25, Alessandro Baretta wrote:
> >> Anil Madhavapeddy wrote:
> >> >>>x ++ f ++ g ++ h
> >> >>
> >> >>What is the impact of the this programming style on execution
> >> >> performance?
> >
> > 1. It should be easy enough to extend the syntax so that you don't have to 
> > worry about it getting compiled away.
> >
> > 2. Mathematica uses notation x // f. Why not use the same? Many people will 
> > misunderstand ++ as something coming from C.
> 
> Those of use who don't use Mathematica will misunderstand that as a
> comment (from C++), or an integer divide (Python), or ...?

Well, I see ++ as string or list append, since that's what Haskell uses.

Dave

Re: [Caml-list] Re: Question on performance/style issue

[Alessandro Baretta]

David Brown wrote:
> On Mon, Feb 27, 2006 at 05:37:37PM -0500, David M. Cooke wrote:
> 
>>Andrej Bauer <Andrej.Bauer@andrej.com> writes:
>>Those of use who don't use Mathematica will misunderstand that as a
>>comment (from C++), or an integer divide (Python), or ...?
> 
> 
> Well, I see ++ as string or list append, since that's what Haskell uses.

(++) is used in the compiler. I don't use Mathematica, so I don't feel (//) is 
any more idiomatic than (++).

Alex

-- 
*********************************************************************

Ing. Alessandro Baretta

Studio Baretta
http://studio.baretta.com/

Consulenza Tecnologica e Ingegneria Industriale
Technological Consulting and Industrial Engineering

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Re: [Caml-list] Question on performance/style issue

[Alessandro Baretta]

Andrej Bauer wrote:
> On Friday 24 February 2006 20:25, Alessandro Baretta wrote:
>
> 1. It should be easy enough to extend the syntax so that you don't have to 
> worry about it getting compiled away.

One of the most interesting features of Ocaml is the possibility of defining 
operators. I like to stick to standard syntax insofar as possible.

Alex

-- 
*********************************************************************

Ing. Alessandro Baretta

Studio Baretta
http://studio.baretta.com/

Consulenza Tecnologica e Ingegneria Industriale
Technological Consulting and Industrial Engineering

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Re: [Caml-list] Question on performance/style issue

[Nathaniel Gray]

On 2/24/06, Alessandro Baretta <a.baretta@studio.baretta.com> wrote:
> I am very fond of the following "duality" operator.
>
> let (++) x f = f x
>
> I use to write complex computations legibly: instead of
>  > h(g(f(x)))
> I write
>  > x ++ f ++ g ++ h
>
> What is the impact of the this programming style on execution performance?

Looks bad:
================ simpleops.ml =================
let a x = print_string x; x ^ "."
let b x = x ^ x
let c x = "frotz" ^ x

let (++) x f = f x

let test_oper _ =
   " Hello!" ++ a ++ b ++ a ++ b ++ c ++ a ++ b ++ c

let test_normal _ =
   c (b (a (c (b (a (b (a " Hello!")))))))

let _ = test_oper ()
let _ = test_normal ()
============ end simpleops.ml ============

Compiled on a PPC powerbook with:
ocamlopt.opt -S -c simpleops.ml

============= from simpleops.s =============
	.globl	_camlSimpleops__test_oper_66
	.text
	.align	2
_camlSimpleops__test_oper_66:
	mflr	r0
	addi	r1, r1, -32
	stw	r0, 28(r1)
L105:
	addis	r11, 0, ha16(_camlSimpleops+4)
	lwz	r4, lo16(_camlSimpleops+4)(r11)
	addis	r11, 0, ha16(_camlSimpleops)
	lwz	r5, lo16(_camlSimpleops)(r11)
	stw	r4, 0(r1)
	addis	r11, 0, ha16(_camlSimpleops)
	lwz	r4, lo16(_camlSimpleops)(r11)
	addis	r11, 0, ha16(_camlSimpleops+4)
	lwz	r6, lo16(_camlSimpleops+4)(r11)
	lwz	r27, 0(r4)
	addis	r11, 0, ha16(_camlSimpleops+8)
	lwz	r7, lo16(_camlSimpleops+8)(r11)
	addis	r11, 0, ha16(_camlSimpleops)
	lwz	r8, lo16(_camlSimpleops)(r11)
	addis	r11, 0, ha16(_camlSimpleops+4)
	lwz	r9, lo16(_camlSimpleops+4)(r11)
	addis	r11, 0, ha16(_camlSimpleops+8)
	lwz	r10, lo16(_camlSimpleops+8)(r11)
	stw	r9, 20(r1)
	stw	r10, 24(r1)
	stw	r8, 16(r1)
	stw	r7, 12(r1)
	stw	r6, 8(r1)
	stw	r5, 4(r1)
	addis	r3, 0, ha16(_camlSimpleops__8)
	addi	r3, r3, lo16(_camlSimpleops__8)
	mtctr	r27
L106:	bctrl
	lwz	r4, 0(r1)
	lwz	r25, 0(r4)
	mtctr	r25
L107:	bctrl
	lwz	r4, 4(r1)
	lwz	r23, 0(r4)
	mtctr	r23
L108:	bctrl
	lwz	r4, 8(r1)
	lwz	r21, 0(r4)
	mtctr	r21
L109:	bctrl
	lwz	r4, 12(r1)
	lwz	r19, 0(r4)
	mtctr	r19
L110:	bctrl
	lwz	r4, 16(r1)
	lwz	r17, 0(r4)
	mtctr	r17
L111:	bctrl
	lwz	r4, 20(r1)
	lwz	r15, 0(r4)
	mtctr	r15
L112:	bctrl
	lwz	r4, 24(r1)
	lwz	r10, 0(r4)
	mtctr	r10
	lwz	r11, 28(r1)
	addi	r1, r1, 32
	mtlr	r11
	bctr
=========================================

Compare that with
=========================================
	.globl	_camlSimpleops__test_normal_67
	.text
	.align	2
_camlSimpleops__test_normal_67:
	mflr	r0
	addi	r1, r1, -16
	stw	r0, 12(r1)
L113:
	addis	r3, 0, ha16(_camlSimpleops__7)
	addi	r3, r3, lo16(_camlSimpleops__7)
L114:	bl	_camlSimpleops__a_57
	mr	r4, r3
L115:	bl	_camlPervasives__$5e_135
L116:	bl	_camlSimpleops__a_57
	mr	r4, r3
L117:	bl	_camlPervasives__$5e_135
L118:	bl	_camlSimpleops__c_61
L119:	bl	_camlSimpleops__a_57
	mr	r4, r3
L120:	bl	_camlPervasives__$5e_135
	lwz	r11, 12(r1)
	addi	r1, r1, 16
	mtlr	r11
	b	_camlSimpleops__c_61
============== end simpleops.s =============

So no, it looks like the call to ++ isn't compiled away, at least in
this case.  I also tried with -inline 99 and it didn't help, but I
don't know if that's even a valid value for inline.

Cheers,
-n8

--
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

Re: [Caml-list] Question on performance/style issue

[Alessandro Baretta]

Nathaniel Gray wrote:
> On 2/24/06, Alessandro Baretta <a.baretta@studio.baretta.com> wrote:
>
>> x ++ f ++ g ++ h
>>
>>What is the impact of the this programming style on execution performance?
> 
> 
> Looks bad:  ...
> 
> So no, it looks like the call to ++ isn't compiled away, at least in
> this case.  I also tried with -inline 99 and it didn't help, but I
> don't know if that's even a valid value for inline.

Ah, I thought so much. Yet, I also think I remember that ocaml(c/opt) does 
reduce some kinds of expressions before code generation. Or am I out in the blue?

Alex


-- 
*********************************************************************

Ing. Alessandro Baretta

Studio Baretta
http://studio.baretta.com/

Consulenza Tecnologica e Ingegneria Industriale
Technological Consulting and Industrial Engineering

tel. +39 02 370 111 55
fax. +39 02 370 111 54