headers
Florian Weimer | 1 Nov 2005 17:30
Picon

Re: jhc vs ghc and the surprising result involving ghc generated assembly.

* John Meacham:

> loop:
>
> if () goto loop;
>
> is not equivalent to a do-while loop, loop invarients cannot be hoisted out of
> the above for instance (except in some cases... it is all quite tricky and we
> want gcc to have as much freedom as possible).

do-while loops are converted to this form by the compiler (as of
version 4, use the -fdump-tree-* to see the IL), so the problems you
are observing must be caused by something different.

> use C control constructs rather than gotos.

With GCC version 4, this will have no effect because the gimplifier
converts everything to goto-style anyway.
Permalink | Reply | 23 comments |
headers
Florian Weimer | 1 Nov 2005 17:32
Picon

Re: jhc vs ghc and the surprising result involving ghc generatedassembly.

* Simon Marlow:

> gcc started generating this rubbish around version 3.4, if I recall
> correctly.  I've tried disabling various optimisations, but can't seem
> to convince gcc not to generate the extra jump.  You don't get this from
> the native code generator, BTW.

But the comparison is present in the C code.  What do you want GCC to
do?
Permalink | Reply | 1 comment |
headers
skaller | 1 Nov 2005 18:50
Picon

Re: jhc vs ghc and the surprising result involving ghc generated assembly.

On Tue, 2005-11-01 at 17:30 +0100, Florian Weimer wrote:

> > use C control constructs rather than gotos.
> 
> With GCC version 4, this will have no effect because the gimplifier
> converts everything to goto-style anyway.

Felix generates C with gotos. The result is FASTER
than native C using gcc 4.0 on x86_64.

http://felix.sourceforge.net/current/speed/en_flx_perf_0005.html

C code:

     4: int Ack(int M, int N) {
     5:   if (M==0) return N +1;
     6:   else if(N==0) return Ack(M-1,1);
     7:   else return Ack(M-1, Ack(M,N-1));
     8: }
     9: 

It is known gcc is correctly optimising tail calls here.

Felix:

     5: fun ack(x:int,y:int):int =>
     6:   if x == 0 then y + 1
     7:   elif y == 0 then ack(x-1, 1)
     8:   else ack(x-1, ack(x, y-1))
     9:   endif
(Continue reading)

Permalink | Reply | 14 comments |
headers
Florian Weimer | 1 Nov 2005 19:03
Picon

Re: jhc vs ghc and the surprising result involving ghc generated assembly.

* > On Tue, 2005-11-01 at 17:30 +0100, Florian Weimer wrote:
>
>> > use C control constructs rather than gotos.
>> 
>> With GCC version 4, this will have no effect because the gimplifier
>> converts everything to goto-style anyway.
>
> Felix generates C with gotos. The result is FASTER
> than native C using gcc 4.0 on x86_64.

Coincidence. 8-)

> Felix generated C(++) code -- compiled with same options:
>
> int FLX_REGPARM _i1860_f1301_ack( 
> int _i1864_v1303_x, int _i1865_v1304_y)
> {
>   _us2 _i1867_v1799_ack_mv_74;
>   _us2 _i1868_v1821_ack_mv_84;

_us2 is unsigned, correct?

BTW, you shouldn't generate identifiers with leading underscores
because they are reserved for the implementation.

> I have no real idea why the Felix generated C is faster.
> Two guesses:
>
> (a) the two 'mv' variables declared at the top are optimised
> away, so the Felix version is only using 3 words of stack.
(Continue reading)

Permalink | Reply | 13 comments |
headers
skaller | 1 Nov 2005 22:16
Picon

Re: jhc vs ghc and the surprising result involving ghc generated assembly.

On Tue, 2005-11-01 at 19:03 +0100, Florian Weimer wrote:

> > Felix generates C with gotos. The result is FASTER
> > than native C using gcc 4.0 on x86_64.
> 
> Coincidence. 8-)

Possibly :)

> > Felix generated C(++) code -- compiled with same options:
> >
> > int FLX_REGPARM _i1860_f1301_ack( 
> > int _i1864_v1303_x, int _i1865_v1304_y)
> > {
> >   _us2 _i1867_v1799_ack_mv_74;
> >   _us2 _i1868_v1821_ack_mv_84;
> 
> _us2 is unsigned, correct?

No, actually it means 'unit sum', in this case the
sum of two units (hence us2). Felix has a special representation
for unit sums .. it uses an int. And of course, 

	1 + 1 = 2

is just another name for 'bool'. These two variables are
'mv's or 'match variables' -- the arguments of the two matches
which are generated by the 'if then elif else endif' sugar.
Match expressions are stuck into variables so they can be
destructed by pattern matching (even though in this case
(Continue reading)

Permalink | Reply | 12 comments |
headers
John Meacham | 2 Nov 2005 01:54
Favicon

Re: jhc vs ghc and the surprising result involving ghc generatedassembly.

On Tue, Nov 01, 2005 at 05:32:29PM +0100, Florian Weimer wrote:
> * Simon Marlow:
> 
> > gcc started generating this rubbish around version 3.4, if I recall
> > correctly.  I've tried disabling various optimisations, but can't seem
> > to convince gcc not to generate the extra jump.  You don't get this from
> > the native code generator, BTW.
> 
> But the comparison is present in the C code.  What do you want GCC to
> do?

in addition to the expected conditional jump, it is adding another
unconditional jump and an indirect jump to a constant.
        John

--

-- 
John Meacham - ⑆repetae.net⑆john⑈
Permalink | Reply | 0 comments |
headers
Simon Marlow | 2 Nov 2005 11:42
Picon
Favicon

RE: jhc vs ghc and the surprising result involving ghc generatedassembly.

On 01 November 2005 16:32, Florian Weimer wrote:

> * Simon Marlow:
> 
>> gcc started generating this rubbish around version 3.4, if I recall
>> correctly.  I've tried disabling various optimisations, but can't
>> seem to convince gcc not to generate the extra jump.  You don't get
>> this from the native code generator, BTW.
> 
> But the comparison is present in the C code.  What do you want GCC to
> do?

I didn't mean to sound overly critical of gcc.  But here's what I was
complaining about - the code generated by gcc (3.4.x) is as follows:

Main_zdwfac_info:
.text
	.align 8
	.text
	movq	(%rbp), %rdx
	cmpq	$1, %rdx
	jne	.L2
	movq	8(%rbp), %r13
	leaq	16(%rbp), %rbp
	movq	(%rbp), %rax
.L4:
	jmp	*%rax
.L2:
	movq	%rdx, %rax
	imulq	8(%rbp), %rax
(Continue reading)

Permalink | Reply | 4 comments |
headers
Rene de Visser | 2 Nov 2005 12:15
Picon
Favicon

Array operations and pinning

Hello,

Where is the documentation on how pinning works in the GHC garbage collector 
(from a GHC users point of view).

I have copied the following code from array/IO.hs and am thinking that it is 
assuming that the array is pinned? What triggers the pinning?

On a second note.
Why is the type signiture so constricted. The code below works on any 
IOUArray (which is very usefull, not just on Int Word8). Naturally this 
assumes the particular in memory array layout that GHC uses on a particular 
platform, so would not be compatible (probably) with other Haskell 
compilers.

Rene.

hPutArray
	:: Handle			-- ^ Handle to write to
	-> IOUArray Int Word8		-- ^ Array to write from
	-> Int				-- ^ Number of 'Word8's to write
	-> IO ()

hPutArray handle (IOUArray (STUArray l u raw)) count
  | count == 0
  = return ()
  | count < 0 || count > rangeSize (l,u)
  = illegalBufferSize handle "hPutArray" count
  | otherwise
   = do wantWritableHandle "hPutArray" handle $
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Finch | 2 Nov 2005 13:26
Picon
Favicon

Re: jhc vs ghc and the surprising result involving ghc generated assembly.

On Wed, 2 Nov 2005, skaller wrote:
> On Tue, 2005-11-01 at 19:03 +0100, Florian Weimer wrote:
>
> > BTW, you shouldn't generate identifiers with leading underscores
> > because they are reserved for the implementation.
>
> I AM the implementation :)

You are not the C implementation.

> Generated Identifiers start with underscores,
> so they don't clash with arbitrary C code.

You should prefix them with something else, e.g. felix_.

Tony.
--

-- 
f.a.n.finch  <dot <at> dotat.at>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.
Permalink | Reply | 0 comments |
headers
Simon Marlow | 2 Nov 2005 13:39
Picon
Favicon

RE: Array operations and pinning

On 02 November 2005 11:15, Rene de Visser wrote:

> Where is the documentation on how pinning works in the GHC garbage
> collector (from a GHC users point of view).
> 
> I have copied the following code from array/IO.hs and am thinking
> that it is assuming that the array is pinned? What triggers the
> pinning? 

Actually this code does not assume that any memory is pinned.  It is ok
to pass the underlying ByteArr# directly to C, as long as the C call is
annotated "unsafe", which means that GC cannot happen while the call is
running.

If you want to pass ByteArr# to a "safe" C call, then you have to
allocate the ByteArr# using newPinnedByteArray#.  This is the only way
to get a pinned object in GHC, and the only kind of pinned object that
is supported is a MutByteArr# or ByteArr# (this is to simplify the GC;
it doesn't need to traverse pinned objects because they don't contain
any pointers, all it needs to do is remember that the memory block they
occupy is still alive).

Note that all this is GHC-specific; the right high-level interface to
allocating pinned memory is mallocForeignPtr.

> On a second note.
> Why is the type signiture so constricted. The code below works on any
> IOUArray (which is very usefull, not just on Int Word8). Naturally
> this assumes the particular in memory array layout that GHC uses on a
> particular platform, so would not be compatible (probably) with other
(Continue reading)

Permalink | Reply | 7 comments |

Gmane