Warp wrote:

>> Notionally, no.
> 
>> Physically? Ask the optimiser.
> 
>   One thing which bothers me with haskell is the amount of features which
> rely solely on the compiler being able to optimize them.

You're used to C++, where what you tell the computer to do is *exactly* 
what the computer does. (Or very close to it.)

The C++ way means that if you're clever, you can write very performant 
code. The Haskell way means that if the compiler suddenly gets smarter, 
your existing code speeds up. (Although the fact that it's speeding up 
implies that it was slower than necessary before.)

> For example a
> simple thing like "go through this subrange inside this list and calculate
> the sum of the elements", which you usually do in-place, becomes something
> which at the language level requires copying (needlessly) the subrange just
> so that you can traverse it, and hoping that the compiler will be able to
> figure out what is it that you are really doing and optimizing the copying
> away.

In this specific case, I'm particularly confident that the compiler can 
work it out. (But - as you point out - that's because I have some idea 
about how this is working internally.)

>   I don't know... This kind of defeats the whole purpose of a high-level
> language where you are supposed to not to have to worry about internal
> implementation details of the compiler.

To an extent, yes.

I think of it as being somewhat like SQL. If you write some random chunk 
of SQL, you can know what the result will be. But how will this result 
be computed? Well, *that* would depend on exactly which database product 
from which vendor with which configuration settings, what indexes have 
been built, what the size of the tables is, how the optimiser has been 
configured...

Now, if it's your job to make sure certain critical queries run fast, 
you will know the particular database you're using and what to do to the 
query to speed it up. You'll look at query plans to see what the 
database is doing, and what might be worth changing. (GHC allows you to 
do something conceptually similar.)

Does having to rephrase an SQL query to make it faster "defeat the 
purpose of SQL"? Not so much. It's unfortunate that it's necessary, but 
it doesn't stop SQL from being a hugely useful thing.

If you want to write performant code in C++, you had better go learn 
about call-by-name vs call-by-reference and how virtual methods are 
implemented and a whole bunch of stuff if you expect your code to be 
performant. C++ doesn't pretend otherwise. In Haskell, you need to have 
some idea how the abstractions you're playing with are implemented too. 
Typically you don't need a really in-depth technical understanding, but 
you do need to have some clue how the machine is doing this stuff.

I guess if you're writing something where efficiency is the absolute 
maximum priority, Haskell perhaps isn't the best possible choice. But 
for the kind of code *I* write, the program is so complicated 
algorithmically that getting it to *work properly* is the top priority. 
(Ever heard the phrase "implement first, optimise second"?) So maybe 
it's just that you and I write different code. My code tends not to be 
performance-critical.

Post a reply to this message