Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]

[Rustom Mody]

On Tue, Jun 4, 2013 at 7:35 AM, Richard A. O'Keefe wrote:

>
> On 3/06/2013, at 6:58 PM, Carter Schonwald wrote:
> > If the Int type had either of these semantics by default, many many
> performance sensitive libraries would suddenly have substantially less
> compelling performance.  Every single operation that was branchless before
> would have a branch *every* operation. this would be BAD.
>
> Actually, the x86 can be configured to trap integer overflows,
> so on that not entirely unpopular platform, there need be NO
> extra branches.
>

Well yes and no. See http://software.intel.com/en-us/forums/topic/306156
Using instructions like cmovo "Conditional MOve on Overflow" we can test
without a branch -- so in that sense yes.

No, because the use of the word 'trap' is a bit misleading. If we
understand 'trap' as synchronous interrupt, then intel provides the
infrastructure to literally trap floating point errors but for integers
such a 'trap' only works if the instruction stream contains instructions
like INTO or CMOVO etc.


>
> Alternatively, and more portably, there could be separate
> Int and UnsafeInt types, and the performance sensitive libraries
> could be rewritten to use UnsafeInt.
>
> For just one week, I had the joy of using a C compiler where
> signed integer overflow was trapped.  It was *wonderful*.
>
>
In Discipline of Programming (in 1976!) Dijkstra exactly described this
problem, and squarely put the blame on poorly engineered machines.
He introduced 3 concepts/terms:
UM : unbounded machine
SLM : sufficiently large machine
HSLM : hopefully sufficiently large machine

The UM -- like a Turing machine -- has no messy restrictions of finiteness
like wordsize and is therefore pleasant to reason with and impossible to
physically build.

The SLM is like most of our actual machines -- actual finite state machines
approximating our conceptually nice unbounded machines. The problem is when
the approximation fails, the SLM behaves unpredictably.

So we have the HSLM, which (I quote):

The HSLM is two things merged into one. Besides acting as the largest SLM
we can afford, it checks, when called to execute a program, as the
computation proceeds, whether this SLM is large enough for the current
computation.  If so, it proceeds with the simulation of the UM's behaviour,
otherwise it refuses to continue.

There exist, regretfully enough,in which the continuous check that the
simulation of the behaviour of the UM is not beyond their capacity is so
time-consuming, that the check is suppressed for the sake of efficiency.

It is very difficult to use such machines… and we ignore them in the
sequel!!

In short the problem is our machines: if catching errors involves checking
and checking involves a cost, some program(ers) will sometimes seek to
avoid that.
Moving the check to the hardware -- ie synchronous trap on errors --
removes the cost and the temptation to avoid.

Until we get such machines, these arguments will continue to be there!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Array, Vector, Bytestring

[briand]

On Mon, 3 Jun 2013 23:19:38 -0400
Clark Gaebel  wrote:

> That's absolutely true. Wrappers around vector for your multidimensional
> access is probably best, but Vectors of Vectors are usually easier.
> 
> But again, you're right. Multidimensional access is a pain. If it's a
> "matrix" of numerical values, you could take a look at 'hmatrix'.

or repa


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Array, Vector, Bytestring

[Clark Gaebel]

That's absolutely true. Wrappers around vector for your multidimensional
access is probably best, but Vectors of Vectors are usually easier.

But again, you're right. Multidimensional access is a pain. If it's a
"matrix" of numerical values, you could take a look at 'hmatrix'.

  - Clark

On Monday, June 3, 2013, Jason Dagit wrote:

> On Mon, Jun 3, 2013 at 7:45 PM, Clark Gaebel 
> >
> wrote:
> > How is this a problem?
> >
> > If you're representing text, use 'text'.
> > If you're representing a string of bytes, use 'bytestring'.
> > If you want an "array" of values, think c++ and use 'vector'.
> > If you want to mutate arrays, first, make sure you do. You probably
> don't.
> > If you're sure, use MVector.
> >
> > Don't use String, except to interface with legacy code. You probably want
> > 'text'.
> > Don't use Array. Anything it can be used for, can be done with 'vector'.
>
> You have to build multidimensional accessors for vector yourself.
> Array supports them out of the box. I still prefer vector, but it's
> only fair to note that multidimensional data is a weak spot of vector.
>
> Jason
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Array, Vector, Bytestring

[Jason Dagit]

On Mon, Jun 3, 2013 at 7:45 PM, Clark Gaebel  wrote:
> How is this a problem?
>
> If you're representing text, use 'text'.
> If you're representing a string of bytes, use 'bytestring'.
> If you want an "array" of values, think c++ and use 'vector'.
> If you want to mutate arrays, first, make sure you do. You probably don't.
> If you're sure, use MVector.
>
> Don't use String, except to interface with legacy code. You probably want
> 'text'.
> Don't use Array. Anything it can be used for, can be done with 'vector'.

You have to build multidimensional accessors for vector yourself.
Array supports them out of the box. I still prefer vector, but it's
only fair to note that multidimensional data is a weak spot of vector.

Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Array, Vector, Bytestring

[Clark Gaebel]

How is this a problem?

If you're representing text, use 'text'.
If you're representing a string of bytes, use 'bytestring'.
If you want an "array" of values, think c++ and use 'vector'.
If you want to mutate arrays, first, make sure you do. You probably don't.
If you're sure, use MVector.

Don't use String, except to interface with legacy code. You probably want
'text'.
Don't use Array. Anything it can be used for, can be done with 'vector'.

  - Clark

This covers all the use-cases that I can think of.

On Monday, June 3, 2013, wrote:

> On Mon, 03 Jun 2013 19:16:08 +
> silvio > wrote:
>
> > Hi everyone,
> >
> > Every time I want to use an array in Haskell, I find myself having to
> > look up in the doc how they are used, which exactly are the modules I
> > have to import ... and I am a bit tired of staring at type signatures
> > for 10 minutes to figure out how these arrays work every time I use them
> > (It's even worse when you have to write the signatures). I wonder how
> > other people perceive this issue and what possible solutions could be.
>
> My opinion, it's every bit as bad you say it is...
> Not a clue as to what can be done about it.
>
> Probably yet another vector module.
>
>
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org 
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Array, Vector, Bytestring

[briand]

On Mon, 03 Jun 2013 19:16:08 +
silvio  wrote:

> Hi everyone,
> 
> Every time I want to use an array in Haskell, I find myself having to 
> look up in the doc how they are used, which exactly are the modules I 
> have to import ... and I am a bit tired of staring at type signatures 
> for 10 minutes to figure out how these arrays work every time I use them 
> (It's even worse when you have to write the signatures). I wonder how 
> other people perceive this issue and what possible solutions could be.

My opinion, it's every bit as bad you say it is...
Not a clue as to what can be done about it.

Probably yet another vector module.





___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]

[Richard A. O'Keefe]

On 3/06/2013, at 6:58 PM, Carter Schonwald wrote:
> If the Int type had either of these semantics by default, many many 
> performance sensitive libraries would suddenly have substantially less 
> compelling performance.  Every single operation that was branchless before 
> would have a branch *every* operation. this would be BAD. 

Actually, the x86 can be configured to trap integer overflows,
so on that not entirely unpopular platform, there need be NO
extra branches.

Alternatively, and more portably, there could be separate
Int and UnsafeInt types, and the performance sensitive libraries
could be rewritten to use UnsafeInt.

For just one week, I had the joy of using a C compiler where
signed integer overflow was trapped.  It was *wonderful*.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Array, Vector, Bytestring

[Ben Gamari]

Artyom Kazak  writes:

> silvio  писал(а) в своём письме Mon, 03 Jun 2013  
> 22:16:08 +0300:
>
>> Hi everyone,
>>
>> Every time I want to use an array in Haskell, I find myself having to  
>> look up in the doc how they are used, which exactly are the modules I  
>> have to import ... and I am a bit tired of staring at type signatures  
>> for 10 minutes to figure out how these arrays work every time I use them  
>> (It's even worse when you have to write the signatures). I wonder how  
>> other people perceive this issue and what possible solutions could be.
>
> Recently I’ve started to perceive this issue as “hooray, we have lenses  
> now, a generic interface for all the different messy stuff we have”. But  
> yes, the inability to have One Common API for All Data Structures is  
> bothering me as well.
>
>> Why do we need so many different implementations of the same thing? In  
>> the ghc libraries alone we have a vector, array and bytestring package  
>> all of which do the same thing, as demonstrated for instance by the  
>> vector-bytestring package. To make matters worse, the haskell 2010  
>> standard has includes a watered down version of array.
>
> Indeed. What we need is `text` for strings (and stop using `bytestring`)  
> and reworked `vector` for arrays (with added code from `StorableVector` —  
> basically a lazy ByteString-like chunked array).
>
To be perfectly clear, ByteString and Text target much different
use-cases and are hardly interchangeable. While ByteString is, as the
name suggests, a string of bytes, Text is a string of characters in a
Unicode encoding. When you are talking about unstructured binary data,
you should most certainly be using ByteString.

Cheers,

- Ben

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Array, Vector, Bytestring

[Artyom Kazak]

silvio  писал(а) в своём письме Mon, 03 Jun 2013  
22:16:08 +0300:



Hi everyone,

Every time I want to use an array in Haskell, I find myself having to  
look up in the doc how they are used, which exactly are the modules I  
have to import ... and I am a bit tired of staring at type signatures  
for 10 minutes to figure out how these arrays work every time I use them  
(It's even worse when you have to write the signatures). I wonder how  
other people perceive this issue and what possible solutions could be.


Recently I’ve started to perceive this issue as “hooray, we have lenses  
now, a generic interface for all the different messy stuff we have”. But  
yes, the inability to have One Common API for All Data Structures is  
bothering me as well.


Why do we need so many different implementations of the same thing? In  
the ghc libraries alone we have a vector, array and bytestring package  
all of which do the same thing, as demonstrated for instance by the  
vector-bytestring package. To make matters worse, the haskell 2010  
standard has includes a watered down version of array.


Indeed. What we need is `text` for strings (and stop using `bytestring`)  
and reworked `vector` for arrays (with added code from `StorableVector` —  
basically a lazy ByteString-like chunked array).



# Index

I don't really see a reason for having an index of a type other than Int  
and that starts somewhere else than at 0.


It’s a bad idea. I, for one, don’t really see how writing `Vector (Vector  
(Vector Int))` can be considered even remotely satisfying by anyone. And  
if you’re considering 3D arrays “a corner case”, then I’m afraid I can’t  
agree with you.


Also, arrays which allow negative indexing can save a lot of headache and  
prevent mistakes which generally occur when a programmer is forced to  
constantly keep in mind that index 2000 is actually 0 and 0 is −2000.



# Storable vs Unboxed

Is there really a difference between Storable and Unboxed arrays and if  
so can't this be fixed in the complier rather than having to expose this  
problem to the programmer?


Storable seems to be mainly for marshalling, and most people who need it  
are (probably) library writers. I don’t know for sure, though, but it  
doesn’t appear to be a big issue.



# ST s vs IO

This is probably the hardest to resolve issue. The easiest solution is  
probably to just have a module for each of them as in the array package.

I find the PrimState a bit complicated and circuitous.

The ideal solution would be to have

   type IO a = ST RealWorld# a

in the next haskell standard.


Sure, except that IO is actually *not* ST+Realworld, and only happens to  
be implemented like that in GHC (not in JHC, for instance). It has been  
discussed before:  
http://haskell.1045720.n5.nabble.com/IO-ST-RealWorld-td3190075.html . (Not  
to mention people attempting to rewrite RealWorld# values and create havoc  
and fire missiles everywhere expecting them to disappear the very moment  
they smile knowingly and `put` the original RealWorld# back.)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] [ANN] Haskell-Paris meetup

[lucas di cioccio]

Dear all,

I'm happy to announce that the Haskell-Paris group will meet on June 25th
in Paris. Please register (free) at
http://www.meetup.com/haskell-paris/events/122515522/  .
Program is not decided yet (contributions are welcome). We'll update once
we know the lineup.

I don't like to send spammy emails but I would like to take advantage of
this announcement to invite any non-Parisian Haskellers to get in touch
with us (email, twitter, or meetup page) if you are in town. We may an
event scheduled close in time and we can anyway propose a get-together in a
restaurant so that visitors can taste our great food&drink and everyone can
chat about her favorite programming language. I did this type of
semi-planned dinners a few times with some Ruby folks and it's a good way
to build ties :).

Regards,
--Lucas DiCioccio
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] code to HTML

[Malcolm Wallace]

On 3 Jun 2013, at 20:38, Corentin Dupont wrote:

> I'd like to transform a .hs file into a .html file.
> The objective is that the .html file, when rendered, looks exactly the same 
> that the .hs, with the exeption that every function in the code is a link to 
> its haddock documentation.
> Is that possible? 

Programatica could do this ten years ago.  But it sort-of fell by the wayside.  
Maybe there is some code still available that could be dusted off and revived:

http://ogi.altocumulus.org/~hallgren/h2h.html

Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] code to HTML

[Corentin Dupont]

Hello everybody,
I'd like to transform a .hs file into a .html file.
The objective is that the .html file, when rendered, looks exactly the same
that the .hs, with the exeption that every function in the code is a link
to its haddock documentation.
Is that possible? The result would look like that:

f xs = 
map
headxs

Thanks!
Corentin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Array, Vector, Bytestring

[silvio]

   write :: MVector a -> Int -> a -> ST s a


This should have been:
write :: MVector s a -> Int -> a -> ST s a

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Array, Vector, Bytestring

[silvio]

Hi everyone,

Every time I want to use an array in Haskell, I find myself having to 
look up in the doc how they are used, which exactly are the modules I 
have to import ... and I am a bit tired of staring at type signatures 
for 10 minutes to figure out how these arrays work every time I use them 
(It's even worse when you have to write the signatures). I wonder how 
other people perceive this issue and what possible solutions could be.


Eg. look at the type signature for changing a single entry in an array:

* vector package:
write :: PrimMonad m => MVector (PrimState m) a -> Int -> a -> m ()
* array package:
writeArray :: (MArray a e m, Ix i) => a i e -> i -> e -> m ()
* bytestring package:
not available
* a reasonable type signature would be:
write :: MVector a -> Int -> a -> ST s a


# To many different implementations

Why do we need so many different implementations of the same thing? In 
the ghc libraries alone we have a vector, array and bytestring package 
all of which do the same thing, as demonstrated for instance by the 
vector-bytestring package. To make matters worse, the haskell 2010 
standard has includes a watered down version of array.


I personally prefer the vector package but if you want to use libraries 
for strings, I am forced back to use bytesting. And now that Array was 
added to haskell 2010, that will start to pop up more and more.


The multitude of already existing libraries is also why I am writing 
this to haskell-cafe and not spinning yet another implementation.


# Index

I don't really see a reason for having an index of a type other than Int 
and that starts somewhere else than at 0.


While there might be corner cases where such a thing might be useful, it 
is only confusing and irritating for the (presumably) rest of us.


# Storable vs Unboxed

Is there really a difference between Storable and Unboxed arrays and if 
so can't this be fixed in the complier rather than having to expose this 
problem to the programmer?


# ST s vs IO

This is probably the hardest to resolve issue. The easiest solution is 
probably to just have a module for each of them as in the array package.

I find the PrimState a bit complicated and circuitous.

The ideal solution would be to have

  type IO a = ST RealWorld# a

in the next haskell standard. If I understand it correctly this would 
let you declare the types as follows but and still use it in an IO context.


  write :: MVector a -> Int -> a -> ST s a

Would this work? I know it would probably screw up all instances

  instance ... IO where

On the other hand, this is not only an issue with arrays but all 
procedurally accelerated data structures like hash-tables.



Silvio

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]

[Carter Schonwald]

GHC is not the spec, I am talking about GHC Haskell, not Haskell the
standard that I don't use.

On 32bit machines, GHC Int is 32bits. On 64bit GHC on 64bit machines Int is
64 bits.

If you have another well engineered suitable for wide use Haskell compiler
in mind, I'd love to try it out, but with interesting software you will be
using none portable features per target platform. And thats OK. Its a
tradeoff thats sometimes worth making.
On Jun 3, 2013 4:19 AM, "Tommy Thorn"  wrote:

> On Jun 3, 2013, at 00:23 , Carter Schonwald 
> wrote:
>
> > Int is "native register sized integer"
>
> Actually it's not. Read the definition. Int is only guaranteed to be 29
> bits.
>
> Here's *one* _actual_ data point (from a 2.8 GHz i7, 64-bit code):
>
> time ./fib
> fib(43) = 701408733
> 3.27 real 3.27 user 0.00 sys
> time ./fib-safe
> fib(43) = 701408733
> 3.45 real 3.45 user 0.00 sys
>
> (NB: I do not check the n-1 and n-2 as it's trivial to see from a data
> flow analysis
> that the proceeding conditional guarantees that those can't overflow.
> The empty asm() is necessary to get GCC to generate comparable code).
>
>
>
>
> Obviously, for some examples this will be much worse, for others, much
> better, but without
> this implemented in GHC it will be difficult to measure.
>
> Tommy
>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]

[Tommy Thorn]

On Jun 3, 2013, at 00:23 , Carter Schonwald  wrote:

> Int is "native register sized integer"

Actually it's not. Read the definition. Int is only guaranteed to be 29 bits.

Here's *one* _actual_ data point (from a 2.8 GHz i7, 64-bit code):

time ./fib
fib(43) = 701408733
3.27 real 3.27 user 0.00 sys
time ./fib-safe
fib(43) = 701408733
3.45 real 3.45 user 0.00 sys

(NB: I do not check the n-1 and n-2 as it's trivial to see from a data flow 
analysis
that the proceeding conditional guarantees that those can't overflow.
The empty asm() is necessary to get GCC to generate comparable code).



fib.c
Description: Binary data


Obviously, for some examples this will be much worse, for others, much better, 
but without
this implemented in GHC it will be difficult to measure.

Tommy

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Announce: Leksah 0.13.2.2 (still a bit experimental)

[Hamish Mackenzie]

It looks like I left a DLL out of the installer.

Fixed versions are here...
http://leksah.org/packages/leksah-0.13.2.3-ghc-7.0.3.exe
http://leksah.org/packages/leksah-0.13.2.3-ghc-7.0.4.exe
http://leksah.org/packages/leksah-0.13.2.3-ghc-7.4.1.exe
http://leksah.org/packages/leksah-0.13.2.3-ghc-7.4.2.exe
http://leksah.org/packages/leksah-0.13.2.3-ghc-7.6.3.exe

On 2 Jun 2013, at 23:22, Hamish Mackenzie  wrote:

> Mostly just a refresh of the current development version
> binary installers, so people can use it with the latest
> Haskell Platform (which uses GHC 7.6.3).
> 
> Unfortunately an official 0.14 release may still be a
> be a way off.
> 
> I have been doing some work on getting Code Mirror working,
> but there are threading issues that will need to be
> resolved before it works (so best to leave the editor
> config set to GtkSourceView).
> 
> I recommend you remove your ~/.leksah-0.13/prefs.lkshp
> file before installing as the format has changed slightly
> and it is not backwards compatibly.
> 
> Hop on #leksah if you have any questions. 
> 
> 
> OS X (Still no WebKit features)
> ---
> Choose the version that matches your installed GHC
> http://leksah.org/packages/leksah-0.13.2.2-ghc-7.0.4.dmg
> http://leksah.org/packages/leksah-0.13.2.2-ghc-7.4.1.dmg
> http://leksah.org/packages/leksah-0.13.2.2-ghc-7.4.2.dmg
> http://leksah.org/packages/leksah-0.13.2.2-ghc-7.6.3.dmg
> 
> Sorry, I am still having trouble building WebKitGTK+ on OSX.
> 
> If you want a challenge...
> https://github.com/jralls/gtk-osx-build
> https://github.com/leksah/leksah/blob/master/osx/gtk.sh
> 
> Alternatively we might have to build Leksah with -f-webkit
> to leave out the webkit stuff.
> 
> 
> Windows
> ---
> Choose the version that matches your installed GHC
> http://leksah.org/packages/leksah-0.13.2.2-ghc-7.0.3.exe
> http://leksah.org/packages/leksah-0.13.2.2-ghc-7.0.4.exe
> http://leksah.org/packages/leksah-0.13.2.2-ghc-7.4.1.exe
> http://leksah.org/packages/leksah-0.13.2.2-ghc-7.4.2.exe
> http://leksah.org/packages/leksah-0.13.2.2-ghc-7.6.3.exe
> 
> 
> Linux
> -
> Follow the steps in the .travis.yml file...
> https://github.com/leksah/leksah/blob/master/.travis.yml
> Should go something like this...
> https://travis-ci.org/leksah/leksah


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]

[Carter Schonwald]

Tommy, respectfully,

I have quite a few bits of code where a bad branch predictor in a tight
inner loops makes code 10x slower.

you are welcome to do your own experimentation so that you too can learn by
branches are bad in tight loops.  (even if the branch predictor is doing
its job, there will be a measurable slow down, albeit less than 10x)

Please shift this conversation to the libraries list if you want to
actually make a concrete libraries change proposal. Otherwise I don't
understand your contentions. Int is "native register sized integer" not
"integer that i need to exception handle because I used int instead of
integer because of premature optimization in my web app or project euler
codes"

My opinions are based upon spending all of my time over the past year
working on writing robustly performant numerical codes. Some of them are
actually faster than the standard fortran ones.

My point being: as mentioned above, by others much more articulate than I,
unless you have performance related reasons, always use Integer instead of
Int. There is never a good reason to use Int instead of Integer unless it
will change the performance characteristics of your code. Asking for Int to
pretend to be Integer because you wanted to do premature optimization and
then it didn't behave like Integer is a no go.

I am happy to direct you towards further reading if you'd like to learn
about writing performance sensitive software:

the intel optimization
manualhas
many good ideas (eg Structure of Arrays, which is essentially used by
the haskell Vector lib) that are actually realized by the more performant
haskell libraries.

 Likewise, for an informative idea of the cost models for various
operations on the CPU, the agner fog
 manuals
are actually very educational.

merry hacking
-Carter



On Mon, Jun 3, 2013 at 3:07 AM, Tommy Thorn  wrote:

> On Jun 2, 2013, at 23:58 , Carter Schonwald 
> wrote:
>
> > Indeed, as Dan says, theres the safeint library and the Integer type.
> >
> > If the Int type had either of these semantics by default, many many
> performance sensitive libraries would suddenly have substantially less
> compelling performance.  Every single operation that was branchless before
> would have a branch *every* operation. this would be BAD.
>
> I'd like to see actual data, measurements of actual wall-time impact on
> real code on modern hardware,
> not assumptions.
>
> Tommy
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]

[Tommy Thorn]

On Jun 2, 2013, at 23:58 , Carter Schonwald  wrote:

> Indeed, as Dan says, theres the safeint library and the Integer type. 
> 
> If the Int type had either of these semantics by default, many many 
> performance sensitive libraries would suddenly have substantially less 
> compelling performance.  Every single operation that was branchless before 
> would have a branch *every* operation. this would be BAD.  

I'd like to see actual data, measurements of actual wall-time impact on real 
code on modern hardware,
not assumptions.

Tommy


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++

[Carter Schonwald]

as the others have said, if you want to have text data go between ghc and
c++, please use Text or Bytestring,

String... would get weird.

If you seriously want to experiment with writing low level code
manipulating the String type, it *MIGHT* be possible using the GHC C minus
minus (CMM). This would be very very very subtle to do correctly, and also
just be really really complicated and hard.

Likewise, for writing a "pure" looking ffi function, a good example is in
the lz4hs lib, where all the allocation occurs on the haskell side, and the
ffi is only mutating freshly allocated memory. Subject to this,
unsafePerformIO can be safely used to give a safe pure thread safe api.

cheers
-Carter


On Sun, Jun 2, 2013 at 10:55 PM, Chris Wong  wrote:

> > The C++/C function (e.g. toUppers) is computation-only and as pure as cos
> > and tan. The fact that marshaling string incurs an IO monad in current
> > examples is kind of unintuitive and like a bug in design. I don't mind
> > making redundant copies under the hood from one type to another..
>
> If you can guarantee that the call is pure, then you can execute it
> directly using `unsafePerformIO`. Simply call the external function as
> usual, then invoke `unsafePerformIO` on the result.
>
> See <
> http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/System-IO-Unsafe.html
> >.
>
> On another note, if you really care about performance, you should use
> the `bytestring` and `text` packages instead of String. They are
> implemented in terms of byte arrays, instead of linked lists, hence
> are both faster and more FFI-friendly.
>
> >
> >
> >
> > On Sun, Jun 2, 2013 at 8:08 PM, Brandon Allbery 
> wrote:
> >>
> >> On Sun, Jun 2, 2013 at 8:01 PM, Thomas Davie 
> wrote:
> >>>
> >>> On 2 Jun 2013, at 16:48, Brandon Allbery  wrote:
> >>>
> >>> (String is a linked list of Char, which is also not a C char; it is a
> >>> constructor and a machine word large enough to hold a Unicode
> codepoint. And
> >>> because Haskell is non-strict, any part of that linked list can be an
> >>> unevaluated thunk which requires forcing the evaluation of arbitrary
> Haskell
> >>> code elsewhere to "reify" the value; this obviously cannot be done in
> the
> >>> middle of random C code, so it must be done during marshalling.)
> >>>
> >>>
> >>> I'm not convinced that that's "obvious" – though it certainly requires
> >>> functions (that go through the FFI) to grab each character at a time.
> >>
> >>
> >> I think you underestimate the complexity of the Haskell runtime and the
> >> interactions between it and the FFI. Admittedly it is probably not
> "obvious"
> >> in the sense of "anyone can tell without knowing anything about it that
> it
> >> can't possibly work", but it should be at least somewhat obvious to
> someone
> >> who sees why there needs to be an FFI in the first place that the
> situation
> >> is not trivial, and that they probably should not blindly assume that
> the
> >> only reason one can't just pass Haskell values directly to C is that
> some
> >> GHC developer was feeling lazy at the time.
> >>
> >> --
> >> brandon s allbery kf8nh   sine nomine
> >> associates
> >> allber...@gmail.com
> >> ballb...@sinenomine.net
> >> unix, openafs, kerberos, infrastructure, xmonad
> >> http://sinenomine.net
> >
> >
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
>
> --
> Chris Wong, fixpoint conjurer
>   e: lambda.fa...@gmail.com
>   w: http://lfairy.github.io/
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]

[Carter Schonwald]

Indeed, as Dan says, theres the safeint library and the Integer type.

If the Int type had either of these semantics by default, many many
performance sensitive libraries would suddenly have substantially less
compelling performance.  Every single operation that was branchless before
would have a branch *every* operation. this would be BAD.

I'm actually quite happy with (ab)using Int as just a sequence of bits that
sometimes i treat as a number, and sometimes i treat as a bitvector. In
fact thats actually most of my work these days. GHC generates VERY nice
code for Ints and Words, similar to what i'd expect to be Generated by a
decent C compiler when not explicitly using SIMD operations.  This is a
good thing!

Additionally, theres work in progress to support "branchless" Bool
operations in GHC by having Bool be represented internally With 0,1 valued
Ints, http://hackage.haskell.org/trac/ghc/wiki/PrimBool

point being: its easy to have the safety with SafeInt, or Using Integer,
and fast inner loops can't have branches, and that actually matters in many
applications.

cheers
-Carter


On Sun, Jun 2, 2013 at 6:42 PM, Dan Doel  wrote:

> There is a package that implements an Int that throws an exception on
> overflow:
>
> http://hackage.haskell.org/package/safeint
>
> Since Int's existence is pretty much all about trading for performance, I
> wouldn't recommend holding your breath on the above becoming the default.
>
> If you want things to work like Scheme, that's exactly what Integer is (in
> GHC, anyhow). And Integer is what you get by default(ing) unless you use
> something else that is specifically defined to use Int, or specify it
> yourself.
>
>
>
> On Sun, Jun 2, 2013 at 5:02 PM, Tommy Thorn  wrote:
>
>> On Jun 2, 2013, at 12:52 , Henry Laxen 
>> wrote:
>>
>> > Yes, that was it.  The dell was a 32 bit system, and the desktop a 64.
>>  I
>> > changed everything from Int to Integer, and now both agree.  Thanks for
>> the
>> > pointer.
>>
>> Isn't that just terrible? I hate the fact that Haskell was defined to
>> neither trap the overflow
>> or just treat everything as Integer [like Scheme]. A sacrifice of program
>> safety in the name
>> of efficiency.
>>
>> I disagree with this choice and posit that a clever implementation can
>> minimize the cost
>> of the overflow checking in most relevant cases.
>>
>> I wish this fatal flaw would be reconsidered for the next major revision.
>>
>> Tommy
>>
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe