OT (partially): about promotion of integers

Timon Gehr timon.gehr at gmx.ch
Wed Dec 12 15:23:01 PST 2012


On 12/12/2012 10:35 PM, Walter Bright wrote:
> On 12/12/2012 12:01 PM, Timon Gehr wrote:
>> That is certainly fixable. It is a mere QOI issue.
>
> When you have a language that fundamentally disallows mutation,

It does not.

> some algorithms are doomed to be slower.

Here's a (real) quicksort:
http://stackoverflow.com/questions/5268156/how-do-you-do-an-in-place-quicksort-in-haskell

> I asked Erik Maijer, one of the developers of
> Haskell, if the implementation does mutation "under the hood" to make
> things go faster.

"under the hood", obviously there must be mutation as this is how the 
machine works.

>  He assured me that it does not, that it follows the
> "no mutation" all the way.
>

Maybe he misunderstood. i.e. DMD does not do this to immutable data 
either. eg. Control.Monad.ST allows in-place state mutation of data 
types eg. from Data.STRef and Data.Array.ST. Such operations are 
sequenced and crosstalk between multiple such 'threads' is excluded by 
the type system, as long as only safe operations are used.

It is somewhat similar to (the still quite broken) 'pure' in D, but 
stronger. (e.g. it is possible to pass mutable references into the rough 
equivalent of 'strongly pure' code, but that code won't be able to read 
their values, the references can appear as part of the return type, and 
the caller will be able to access them again -- Done using basically 
nothing but parametric polymorphism, which D lacks.)


Eg:

 > runST $ do           -- ()pure{
     x <- newSTRef 0    -- auto x = 0;
     writeSTRef x 2     -- x = 2; // mutate x
     y <- readSTRef x   -- auto y = x;
     writeSTRef x 3     -- x = 3; // mutate x
     z <- readSTRef x   -- auto z = x;
     return (y,z)       -- return tuple(y,z);}();
(2,3)                  -- tuple(2,3)


This paper describes how this is implemented in GHC (in-place mutation)
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.3299

The only reason I can see why this is not as fast as D is implementation 
simplicity on the compiler side.

Here is some of the library code. It makes use of primitives (intrinsics):
http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-ST.html#ST

>
>> I think the factor GHC/DMD cannot be more than about 2 or 3 for roughly
>> equivalently written imperative code.
>
> A factor of 2 or 3 is make or break for a large class of programs.
>
> Consider running a server farm. If you can make your code 5% faster, you
> need 5% fewer servers. That translates into millions of dollars.

Provided the code is correct.


More information about the Digitalmars-d mailing list