By the time we release 2.10, we should have darcs dependencies be the
one provided by the current Haskell Platform.

See discussion in http://bugs.darcs.net/patch1095

Next Haskell Platform release is in november 2013.

Link to check current HP: http://www.haskell.org/platform/changelog.html

Re the hashable dependency, darcs seems to compile ok with hashable 
1.1.2.5, though I haven't run the tests. Do we know if there is really a 
specific need for 1.2?

For the containers dependency, patience diff is using Data.Map.Strict 
from containers 0.5. I have a patch ready to go that embeds the source 
for that module+dependencies inside darcs, under the namespace 
Darcs.Data.Map.Strict (etc), and is used conditionally if we are 
building with containers 0.4.

Please shout if you think this is too horrible to contemplate!

There is not an specific need for hashable 1.2. It should work
perfectly with any version since 1.0.0. But there is not a specific
need even for hashable at all, in my test it runs better than the
implementation of hashPS in Darcs.Util.ByteString, so this is why i
added it, but is cumbersome to add a dependency, hashPS could be used
instead of Data.Hashable.hash and avoid this dependency.
I saw that Guillaume get another results in his machine(in his machine
hashPS performs better), so maybe is better to use hashPS? i assume it
depends heavily on the cpu in which it runs.

2013/8/19 Ganesh Sittampalam <bugs@darcs.net>:
>
> Ganesh Sittampalam <ganesh@earth.li> added the comment:
>
> For the containers dependency, patience diff is using Data.Map.Strict
> from containers 0.5. I have a patch ready to go that embeds the source
> for that module+dependencies inside darcs, under the namespace
> Darcs.Data.Map.Strict (etc), and is used conditionally if we are
> building with containers 0.4.
>
> Please shout if you think this is too horrible to contemplate!
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue2338>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel

The hashable dependency is fine, it's just having a dependency that
clashes with the Haskell Platform version that's problematic.

In general I would like for us to use well-maintained external code
(i.e. hashable) instead of our own internal code, but it obviously does
depend on the specifics of the situation.

If hashPS actually does perform better then we should feed that back to
the maintainers of hashable.

Do you have an easily reproducible benchmark that shows the difference
in speed on your machine and Guillaume's? If not, could you provide one?
Might be useful to gather a wider sample.

On 20/08/2013 01:02, José Neder wrote:
> There is not an specific need for hashable 1.2. It should work
> perfectly with any version since 1.0.0. But there is not a specific
> need even for hashable at all, in my test it runs better than the
> implementation of hashPS in Darcs.Util.ByteString, so this is why i
> added it, but is cumbersome to add a dependency, hashPS could be used
> instead of Data.Hashable.hash and avoid this dependency.
> I saw that Guillaume get another results in his machine(in his machine
> hashPS performs better), so maybe is better to use hashPS? i assume it
> depends heavily on the cpu in which it runs.
> 
> 2013/8/19 Ganesh Sittampalam <bugs@darcs.net>:
>>
>> Ganesh Sittampalam <ganesh@earth.li> added the comment:
>>
>> For the containers dependency, patience diff is using Data.Map.Strict
>> from containers 0.5. I have a patch ready to go that embeds the source
>> for that module+dependencies inside darcs, under the namespace
>> Darcs.Data.Map.Strict (etc), and is used conditionally if we are
>> building with containers 0.4.
>>
>> Please shout if you think this is too horrible to contemplate!
>>
>> __________________________________
>> Darcs bug tracker <bugs@darcs.net>
>> <http://bugs.darcs.net/issue2338>
>> __________________________________
>> _______________________________________________
>> darcs-devel mailing list
>> darcs-devel@darcs.net
>> http://lists.osuosl.org/mailman/listinfo/darcs-devel
>

You could use the benchmarks on
http://hub.darcs.net/jlneder/darcs-patience-benchmarks, specifically
use genDiff.sh to get the diff samples and compile and run
CriterionBenchmarks.hs.
My run:
http://hub.darcs.net/jlneder/darcs-patience-benchmarks/raw/CriterionBenchmarks.html
This are the runs from Guilaume:
http://hub.darcs.net/gh/bench/raw/crit2.html
http://hub.darcs.net/gh/bench/raw/crit2b.html

2013/8/20 Ganesh Sittampalam <ganesh@earth.li>:
> The hashable dependency is fine, it's just having a dependency that
> clashes with the Haskell Platform version that's problematic.
>
> In general I would like for us to use well-maintained external code
> (i.e. hashable) instead of our own internal code, but it obviously does
> depend on the specifics of the situation.
>
> If hashPS actually does perform better then we should feed that back to
> the maintainers of hashable.
>
> Do you have an easily reproducible benchmark that shows the difference
> in speed on your machine and Guillaume's? If not, could you provide one?
> Might be useful to gather a wider sample.
>
> On 20/08/2013 01:02, José Neder wrote:
>> There is not an specific need for hashable 1.2. It should work
>> perfectly with any version since 1.0.0. But there is not a specific
>> need even for hashable at all, in my test it runs better than the
>> implementation of hashPS in Darcs.Util.ByteString, so this is why i
>> added it, but is cumbersome to add a dependency, hashPS could be used
>> instead of Data.Hashable.hash and avoid this dependency.
>> I saw that Guillaume get another results in his machine(in his machine
>> hashPS performs better), so maybe is better to use hashPS? i assume it
>> depends heavily on the cpu in which it runs.
>>
>> 2013/8/19 Ganesh Sittampalam <bugs@darcs.net>:
>>>
>>> Ganesh Sittampalam <ganesh@earth.li> added the comment:
>>>
>>> For the containers dependency, patience diff is using Data.Map.Strict
>>> from containers 0.5. I have a patch ready to go that embeds the source
>>> for that module+dependencies inside darcs, under the namespace
>>> Darcs.Data.Map.Strict (etc), and is used conditionally if we are
>>> building with containers 0.4.
>>>
>>> Please shout if you think this is too horrible to contemplate!
>>>
>>> __________________________________
>>> Darcs bug tracker <bugs@darcs.net>
>>> <http://bugs.darcs.net/issue2338>
>>> __________________________________
>>> _______________________________________________
>>> darcs-devel mailing list
>>> darcs-devel@darcs.net
>>> http://lists.osuosl.org/mailman/listinfo/darcs-devel
>>
>

urchin.html: Results from the patience benchmarks on a Debian VM (the rest 
of the system was probably fairly quiet) with GHC 7.4.1. Note that quite a 
few have "variance is severely inflated by outliers".

Attachments

• urchin.html

scafell.html: results from my laptop - an i7-M620 running Windows 7, GHC 7.6.2.

urchin above is a Xeon L3426.

Attachments

• scafell.html

This issue has been fixed thanks to various patches, the last one being
http://bugs.darcs.net/patch1245 . Marking as resolved.