Performance: MD5

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re[2]: Performance: MD5

Bulat Ziganshin-2
Hello Brandon,

Sunday, May 18, 2008, 6:25:31 PM, you wrote:

> Optimization is hard.  Don't like it?  Become a compiler researcher
> and find better ways to do it.  Note that C / procedural language  
> optimization research has at least a 20-year head start on functional
> programming optimization, and that the problems are very different:  
> the C world would love to be at the point where optimizing the C  
> equivalent of "sum xs / length xs" is worth thinking about; they're  
> still not really in a position to *detect* it unless the language is  
> simple enough to make such reasoning relatively easy (e.g. FORTRAN).

and a few lines later you repeat what i said few years ago - ghc
optimization research has got 100x times less attention than C++
optimization so we can't expect the same results in the next 5-10
years at least. strange that you still believe that ghc can optimize
as good as gcc

--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: Performance: MD5

Brandon S Allbery KF8NH

On 2008 May 18, at 10:45, Bulat Ziganshin wrote:

> and a few lines later you repeat what i said few years ago - ghc
> optimization research has got 100x times less attention than C++
> optimization so we can't expect the same results in the next 5-10

Mmm, no.  You tend to say, or at least very strongly imply, "never"  
--- *not* "5-10 years".  (Perhaps this is why you are rarely listened  
to.  Also, perhaps you need to consider how you present things, if  
that's not actually what you mean.)

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[4]: Performance: MD5

Bulat Ziganshin-2
Hello Brandon,

Sunday, May 18, 2008, 6:58:34 PM, you wrote:

>> and a few lines later you repeat what i said few years ago - ghc
>> optimization research has got 100x times less attention than C++
>> optimization so we can't expect the same results in the next 5-10

> Mmm, no.  You tend to say, or at least very strongly imply, "never"  
> --- *not* "5-10 years".  (Perhaps this is why you are rarely listened
> to.  Also, perhaps you need to consider how you present things, if  
> that's not actually what you mean.)

we don't have ghc optimized as good as gcc. when i tell about it, you
tell that i'm not right. then you tell that ghc may be improved in
some future - you don't know exactly. and now you started to watch out
every word i say. well, i can do the same - why you sure that C
optimization was started 20 years before FP optimization? why you sure
that DPH does that i said will be never possible. please answer each
question in detail before trying to critique me. and don't forget that
we still wait from you your great strategy of optimization for C-like
performance using all those fancy DPH/6.8.2 features. or you can only
tell, and tell, and tell but never actually optimized anything?



--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re[4]: Performance: MD5

Brandon S Allbery KF8NH

On 2008 May 18, at 11:10, Bulat Ziganshin wrote:

> we don't have ghc optimized as good as gcc. when i tell about it, you
> tell that i'm not right. then you tell that ghc may be improved in

You're doing a remarkably good job of not hearing what I say.  Hard  
numbers or etc. do nothing whatsoever in the face of "my oresentation  
style is relentless negativity", because I have every expectation  
based on past experience that you will find something else to be  
negative about.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[6]: Performance: MD5

Bulat Ziganshin-2
Hello Brandon,

Sunday, May 18, 2008, 7:15:17 PM, you wrote:
>> we don't have ghc optimized as good as gcc. when i tell about it, you
>> tell that i'm not right. then you tell that ghc may be improved in

> You're doing a remarkably good job of not hearing what I say.  Hard  

may be. so, when i proposed to use low-level optimization, you
contradicted me. lets show us the better way to optimize this
particular program if you know one or stop bothering me

--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re[6]: Performance: MD5

Brandon S Allbery KF8NH

On 2008 May 18, at 11:21, Bulat Ziganshin wrote:

> Hello Brandon,
>
> Sunday, May 18, 2008, 7:15:17 PM, you wrote:
>>> we don't have ghc optimized as good as gcc. when i tell about it,  
>>> you
>>> tell that i'm not right. then you tell that ghc may be improved in
>
>> You're doing a remarkably good job of not hearing what I say.  Hard
>
> may be. so, when i proposed to use low-level optimization, you
> contradicted me. lets show us the better way to optimize this
> particular program if you know one or stop bothering me


Elide the part that says that it's not worth it and repeat yourself  
yet again?  Bah.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
bf3
Reply | Threaded
Open this post in threaded view
|

Re: Performance: MD5

bf3
In reply to this post by Brandon S Allbery KF8NH
As a side note on this discussion, isn't it so that the current CPU
hardware evolved in such a way that it is better suited for imperative
programs? (I'm not talking about the GPU, that's another story). I mean,
hardware gets optimized to run applications faster, but these
applications are mainly written in C/C++, so you get a nice feedback
loop here...

Is it possible to design hardware that is better suitable for functional
languages?







_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[8]: Performance: MD5

Bulat Ziganshin-2
In reply to this post by Brandon S Allbery KF8NH
Hello Brandon,

Sunday, May 18, 2008, 7:24:12 PM, you wrote:

>>> You're doing a remarkably good job of not hearing what I say.  Hard

> Elide the part that says that it's not worth it and repeat yourself  
> yet again?  Bah.

Brandon, you've contradicted to my USEFUL suggestion with a tons of
USELESS sheet and still believe that you are right. well, you are
fanatic which doesn't can't make anything useful but prefer to believe
that his great thoughts was not heard. you can continue to believe, i
will continue to help haskellers. RIP


--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: Performance: MD5

Bulat Ziganshin-2
In reply to this post by bf3
Hello Peter,

Sunday, May 18, 2008, 7:27:35 PM, you wrote:

> As a side note on this discussion, isn't it so that the current CPU
> hardware evolved in such a way that it is better suited for imperative
> programs? (I'm not talking about the GPU, that's another story). I mean,
> hardware gets optimized to run applications faster, but these
> applications are mainly written in C/C++, so you get a nice feedback
> loop here...

i don't think it's fundamental limit. hardware is better suited to
assembler, naturally, but C++ compilers overruled asm. haskell-like
languages can be theoretically compiled to the code which is as good
as asm, it's just not the current state-of-the-art

nevertheless, it's true that new hardware arise and it's two-way
road: FP languages are used more due to multi-core hardware, and
new hardware becomes practically useful due to new ways of programming


--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Performance: MD5

Ketil Malde-5
In reply to this post by bf3
Peter Verswyvelen <[hidden email]> writes:

> Is it possible to design hardware that is better suitable for
> functional languages?

As I recall, Lisp machines went out of business when Lisp ran faster
on industry standard, 68000-based Suns and Apollos, than on their
custom hardware with tags and whatnot.

Anyway - with more and more aggressive caching, and ever increasing
number of cores, it looks like C is an even poorer fit for the
hardware than it used to be - and the Vax model has been a gross
approximation for some time now.  Threading and immutable data is
getting popular even in the bare-metal imperative camp.  Perhaps it is
time to break out of the loop?

-k
--
If I haven't seen further, it is by standing in the footprints of giants
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Performance: MD5

Andrew Coppin
In reply to this post by bf3
Peter Verswyvelen wrote:
> As a side note on this discussion, isn't it so that the current CPU
> hardware evolved in such a way that it is better suited for imperative
> programs? (I'm not talking about the GPU, that's another story). I
> mean, hardware gets optimized to run applications faster, but these
> applications are mainly written in C/C++, so you get a nice feedback
> loop here...
>
> Is it possible to design hardware that is better suitable for
> functional languages?

I wondered about that myself a few times.

For example, current computer designs revolve around a single complex,
fast CPU connected to some slow RAM. [Or, more recently, a very small
number of seperate CPUs.] I wonder what would happen if you instead had
a vast number of very simple proto-processors connected in a vast
network. [But I'm guessing the first thing that'll happen is that the
data is never where you want it to be...]

At any rate, custom hardware vs IA32 is rather like GHC vs GCC - one has
been around for a hell of a lot longer, and had vastly more R&D thrown
at it. Unless you can find some crucial insight that gives you a very
big advantage, you're not going to get anywhere near the market leader
with anything you can come up with by yourself.

(It does seem to be that the major trouble with modern processors is
that they only go fast if there are no cache misses. Back in the days
when RAM was as fast as CPU, you could structure your program any way
you like and it would just work. Today you have to jump through loops to
make sure the cache behaviour is good, or you can just forget it and go
home now. That tends to be a pretty big problem for any programming
language with automatic memory management - Java immediately springs to
mind, but of course Haskell is in the same boat. I get the vague
impression that hardware designers are starting to take notice of the
problem, but it's difficult to see how they could design anything
differently. We'll see I guess... Certainly if hardware appears that
handles OOP languages better, it's likely to handle Haskell better too.)

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Performance: MD5

Achim Schneider
Andrew Coppin <[hidden email]> wrote:

> I wonder what would happen if you instead had
> a vast number of very simple proto-processors connected in a vast
> network. [But I'm guessing the first thing that'll happen is that the
> data is never where you want it to be...]
>
You're not thinking of neuronal networks, are you? The interesting
thing there is that they unite code and data.

--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Performance: MD5

Andrew Coppin
Achim Schneider wrote:

> Andrew Coppin <[hidden email]> wrote:
>
>  
>> I wonder what would happen if you instead had
>> a vast number of very simple proto-processors connected in a vast
>> network. [But I'm guessing the first thing that'll happen is that the
>> data is never where you want it to be...]
>>
>>    
> You're not thinking of neuronal networks, are you? The interesting
> thing there is that they unite code and data.
>  

Damn; you've seen through my cunning disguise. ;-)

In all seriousness, it's easy enough to build an artificial neural
network that computes a continuous function of several continuous
inputs. But it's much harder to see how, for example, you'd build a text
parser or something. It's really not clear how you implement flow
control with this kind of thing. It's so different to a Turing machine
is appears to render most of current computer science irrelevant. And
that's *a lot* of work to redo.

Now, if you had a network of something a bit more complicated than
artificial neurons, but less complicated than an actual CPU... you'd
have... I don't know, maybe something useful? It's hard to say.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
bf3
Reply | Threaded
Open this post in threaded view
|

Re: Performance: MD5

bf3
In reply to this post by Andrew Coppin
Yes, some things might be good for both language paradigms, e.g.

* hardware garbage collection
* hardware transactional memory

With a bit of Googling, both seem to exists, the latter even being
supported by SUN

Andrew Coppin wrote:

> Peter Verswyvelen wrote:
>> As a side note on this discussion, isn't it so that the current CPU
>> hardware evolved in such a way that it is better suited for
>> imperative programs? (I'm not talking about the GPU, that's another
>> story). I mean, hardware gets optimized to run applications faster,
>> but these applications are mainly written in C/C++, so you get a nice
>> feedback loop here...
>>
>> Is it possible to design hardware that is better suitable for
>> functional languages?
>
> I wondered about that myself a few times.
>
> For example, current computer designs revolve around a single complex,
> fast CPU connected to some slow RAM. [Or, more recently, a very small
> number of seperate CPUs.] I wonder what would happen if you instead
> had a vast number of very simple proto-processors connected in a vast
> network. [But I'm guessing the first thing that'll happen is that the
> data is never where you want it to be...]
>
> At any rate, custom hardware vs IA32 is rather like GHC vs GCC - one
> has been around for a hell of a lot longer, and had vastly more R&D
> thrown at it. Unless you can find some crucial insight that gives you
> a very big advantage, you're not going to get anywhere near the market
> leader with anything you can come up with by yourself.
>
> (It does seem to be that the major trouble with modern processors is
> that they only go fast if there are no cache misses. Back in the days
> when RAM was as fast as CPU, you could structure your program any way
> you like and it would just work. Today you have to jump through loops
> to make sure the cache behaviour is good, or you can just forget it
> and go home now. That tends to be a pretty big problem for any
> programming language with automatic memory management - Java
> immediately springs to mind, but of course Haskell is in the same
> boat. I get the vague impression that hardware designers are starting
> to take notice of the problem, but it's difficult to see how they
> could design anything differently. We'll see I guess... Certainly if
> hardware appears that handles OOP languages better, it's likely to
> handle Haskell better too.)
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: Performance: MD5

Bulat Ziganshin-2
In reply to this post by Ketil Malde-5
Hello Ketil,

Sunday, May 18, 2008, 7:44:38 PM, you wrote:

> Anyway - with more and more aggressive caching, and ever increasing
> number of cores, it looks like C is an even poorer fit for the
> hardware than it used to be

doubling number of cores every 1.5 years, we should see 1000-core
monsters just next decade. so, i believe that next decade we will see
the next big language shift and it will be shift toward FP languages.
but Erlang still has more chances - Haskell is too complex, too
slow and not advertised as multithreading language as wide as Erlang was

just now, MS pushes F#. waiting for Sun :)



--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Performance: MD5

Achim Schneider
In reply to this post by Andrew Coppin
Andrew Coppin <[hidden email]> wrote:

> Achim Schneider wrote:
> > Andrew Coppin <[hidden email]> wrote:
> >
> >  
> >> I wonder what would happen if you instead had
> >> a vast number of very simple proto-processors connected in a vast
> >> network. [But I'm guessing the first thing that'll happen is that
> >> the data is never where you want it to be...]
> >>
> >>    
> > You're not thinking of neuronal networks, are you? The interesting
> > thing there is that they unite code and data.
> >  
>
> Damn; you've seen through my cunning disguise. ;-)
>
> In all seriousness, it's easy enough to build an artificial neural
> network that computes a continuous function of several continuous
> inputs. But it's much harder to see how, for example, you'd build a
> text parser or something. It's really not clear how you implement
> flow control with this kind of thing. It's so different to a Turing
> machine is appears to render most of current computer science
> irrelevant. And that's *a lot* of work to redo.
>
Hmmm... fuzzy logic, plus a lot of serialisation of parallel (that is,
right now saved in linear ram) data. Don't make me think about it, or
I'll be forced to confuse you with ramblings about how the brain works.
(Is that control flow? ;)

> Now, if you had a network of something a bit more complicated than
> artificial neurons, but less complicated than an actual CPU... you'd
> have... I don't know, maybe something useful? It's hard to say.

You'd have something like a cell processor, if you go for (more or
less) normal control flow.

Maybe we will soon see dedicated pointer rams, because hardware
manufacturers despair while trying to design a cache manager for 1024
cores: That would make it easy to spot which core holds which pointer,
and thus also easy to move the data to it.

How would a Haskell compiler look like that targets a FPGA? That is,
compiling down to configware, not to a RTS built on top of it.

--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Performance: MD5

Neil Mitchell
Hi

> How would a Haskell compiler look like that targets a FPGA? That is,
> compiling down to configware, not to a RTS built on top of it.

http://www-users.cs.york.ac.uk/~mfn/reduceron2/

Thanks

Neil
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Performance: MD5

Achim Schneider
"Neil Mitchell" <[hidden email]> wrote:

> > How would a Haskell compiler look like that targets a FPGA? That is,
> > compiling down to configware, not to a RTS built on top of it.
>
> http://www-users.cs.york.ac.uk/~mfn/reduceron2/
>
I'm only on page 5 and already drooling.


fact n = 1 (n (==)) 1 (fact (1 (n (-))) (n (*)))
looks somewhat suspiciously like forth to me.

--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Performance: MD5

Aaron Denney
In reply to this post by Andrew Coppin
On 2008-05-18, Andrew Coppin <[hidden email]> wrote:
>> (did you look at the C implementation?)
>>  
>
> I can't read C. (FWIW, I think I did briefly stare at the sources, but
> eventually gave up because I simply had no clue what's going on.)

It's worth learning.  It's still the only widely used abstract
portable assembler with fairly standard ABIs for each platform.

Go read K&R[1].  It shouldn't take more than a week's worth of spare time.

[1]
The C Programming Language (2nd Edition), Kernigan and Ritchie, Prentice Hall, 1998
http://www.amazon.com/Programming-Language-Prentice-Hall-Software/dp/0131103628/

--
Aaron Denney
-><-

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Performance: MD5

Achim Schneider
Aaron Denney <[hidden email]> wrote:

> Go read K&R[1].  It shouldn't take more than a week's worth of spare
> time.
>
HELL NO!

There's a reason why my lecturer always refered to it as "Knall & Rauch
C" (Bang and Smoke C).

Get the Harbison & Steele instead:
http://careferencemanual.com/


--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
123