Regarding my final year thesis

classic Classic list List threaded Threaded
74 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Zac Medico-2
On 11/17/2014 09:47 PM, Andrew Savchenko wrote:
> I use 2.2.14 on both hosts (and usually latest ~x86 portage is
> there). I thought that running fixpackages should be enough to run
> emerge with --dynamic-deps=n.

It depends on how badly the installed deps have diverged from the
corresponding ebuilds in the tree.

> I'm afraid I will not be able to run emerge @changed-deps prior to
> @world update due to too old packages installed (e.g. versions not
> in tree anymore), blockers and unsatisfied deps.

Yeah, it's probably better to run it after, but skip it if emerge
--dynamic-deps=n seems to behave well already.

> When I'll manage to run emerge -DNupv @world without errors, I'll
> send you stats for both runs with and without dynamic deps.

Great, hopefully that will reveal some more good things to optimize.

> By the way, do you need pstats files (e.g. for some extra data) or
> pdf graphs are sufficient?

The pdf graphs are typically enough for me, since they highlight the hot
spots really well. I did not even bother with your pstats files.
--
Thanks,
Zac

Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Zac Medico-2
In reply to this post by Zac Medico-2
On 11/17/2014 07:56 PM, Zac Medico wrote:
> For hitomi, _slot_operator_update_probe/use_reduce is an obvious thing
> to optimize. It called use_reduce 53763 times there, so it seems to
> repeat use_reduce multiple times for the same packages. That means we
> should see a benefit from memoization.

I've written a patch for this [1], and it gives good results (22.4% less
time for dep calc on one of my computers). If you do more profiling, it
would be best to apply this patch first, in order to increase the
contrast for other hot spots.

[1] https://bugs.gentoo.org/show_bug.cgi?id=529660
--
Thanks,
Zac

Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Andrew Savchenko
In reply to this post by Zac Medico-2
Hello,

On Mon, 17 Nov 2014 21:55:48 -0800 Zac Medico wrote:
> On 11/17/2014 09:47 PM, Andrew Savchenko wrote:
> > I use 2.2.14 on both hosts (and usually latest ~x86 portage is
> > there). I thought that running fixpackages should be enough to run
> > emerge with --dynamic-deps=n.
>
> It depends on how badly the installed deps have diverged from the
> corresponding ebuilds in the tree.

I tried fixpackages. It fixed some problems and looks like
dependencies resolution became faster. But not all problems are
fixed and I can't use --dynamic-deps n on both systems for now;
and emerge @changed-deps fails due to numerous conflicts, blocks,
unsatisfied deps (this is not surprising, since it doesn't try to
update all packages in tree).

By the way, is there any way to unroll conflict lists in portage
output? I mean if I have following:

  (dev-lang/ghc-7.6.3-r1:0/7.6.3::gentoo, installed) pulled in by
    >=dev-lang/ghc-6.8.2:0/7.6.3= required by (dev-haskell/random-1.0.1.1-r1:0/1.0.1.1::gentoo, installed)
                        ^^^^^^^^^
    (and 68 more with the same problem)

How can I see all list of these 68 packages? Sometimes this feature is
really desired, e.g. if I don't want to update all @world but need to
apply GLSA fix which leads to similar conflicts. I can't find any
switch in emerge manual.

> > When I'll manage to run emerge -DNupv @world without errors, I'll
> > send you stats for both runs with and without dynamic deps.
>
> Great, hopefully that will reveal some more good things to optimize.
>
> > By the way, do you need pstats files (e.g. for some extra data) or
> > pdf graphs are sufficient?
>
> The pdf graphs are typically enough for me, since they highlight the hot
> spots really well. I did not even bother with your pstats files.
OK. I managed to run emerge -DNupv @world on desktop without
conflicts. What was done:
1) fixpacgkages run
2) portage is updated to use your patch from bug 529660

At this point performance boost was really great: from ~35
minutes to ~19-20 minutes.

Afterward I tried emerge -DNupv @world with different python
versions:
     (2.7)  (~)2.7.8
     (3.3)  3.3.5-r1
     (3.4)  (~)3.4.2

Results are interesting (confidence level for error is 0.95, time
real value was used for calculations):
3.3 is 3% ± 5% faster than 2.7
3.4 is 20% ± 5% faster than 3.3
And with python:3.4 and steps above it takes now 15.5 minutes
instead of 35. Nice result :)

So there is no evidence that portage on 3.3 is faster than on 2.7,
but 3.4 is faster than 3.3 with very good confidence. Of course
this data is biased by -m cProfile overhead, but bias should
similar for each version. Just checked time to run command for
python:3.4 without profiling: it takes 11.5 minutes!

You may find generated pdf graphs together with system information
for each host here:
ftp://brunestud.info/gentoo/portage-v2.tar.xz

As for hitomi box, it is both slower and have much older packages,
so I'm still struggling to fix conflicts and other issues. Results
will be available later.

P.S. Note for those who would like to use gpro2dot: it should be
run with the same python interpreter active as was used during
pstats data collection, otherwise it will fail to process data.
I spent some time while figuring this out.

Best regards,
Andrew Savchenko

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Andrew Savchenko
Hi,

On Wed, 19 Nov 2014 22:59:05 +0300 Andrew Savchenko wrote:
> On Mon, 17 Nov 2014 21:55:48 -0800 Zac Medico wrote:
[...]

> > > When I'll manage to run emerge -DNupv @world without errors, I'll
> > > send you stats for both runs with and without dynamic deps.
> >
> > Great, hopefully that will reveal some more good things to optimize.
> >
> > > By the way, do you need pstats files (e.g. for some extra data) or
> > > pdf graphs are sufficient?
> >
> > The pdf graphs are typically enough for me, since they highlight the hot
> > spots really well. I did not even bother with your pstats files.
>
> OK. I managed to run emerge -DNupv @world on desktop without
> conflicts. What was done:
> 1) fixpacgkages run
> 2) portage is updated to use your patch from bug 529660
>
> At this point performance boost was really great: from ~35
> minutes to ~19-20 minutes.
>
> Afterward I tried emerge -DNupv @world with different python
> versions:
>      (2.7)  (~)2.7.8
>      (3.3)  3.3.5-r1
>      (3.4)  (~)3.4.2
>
> Results are interesting (confidence level for error is 0.95, time
> real value was used for calculations):
> 3.3 is 3% ± 5% faster than 2.7
> 3.4 is 20% ± 5% faster than 3.3
> And with python:3.4 and steps above it takes now 15.5 minutes
> instead of 35. Nice result :)
>
> So there is no evidence that portage on 3.3 is faster than on 2.7,
> but 3.4 is faster than 3.3 with very good confidence. Of course
> this data is biased by -m cProfile overhead, but bias should
> similar for each version. Just checked time to run command for
> python:3.4 without profiling: it takes 11.5 minutes!
>
> You may find generated pdf graphs together with system information
> for each host here:
> ftp://brunestud.info/gentoo/portage-v2.tar.xz
>
> As for hitomi box, it is both slower and have much older packages,
> so I'm still struggling to fix conflicts and other issues. Results
> will be available later.
I managed to get data from hitomi too, see:
ftp://brunestud.info/gentoo/portage-v3.tar.xz
(this archive also contains all graphs previously obtained)

Graphs were obtained the same way as on desktop.
Portage and python versions are the same, time information follows
for _profiled_ runs:

>      (2.7)  (~)2.7.8
real    55m19.892s
user    39m11.913s
sys     15m37.586s

>      (3.3)  3.3.5-r1
real    52m34.640s
user    36m45.325s
sys     15m25.663s

>      (3.4)  (~)3.4.2
real    53m32.657s
user    37m12.369s
sys     15m52.641s

Without profiling using 3.3.5-r1:
real    25m50.439s
user    25m28.260s
sys     0m7.863s

This is quite surprising. On hitomi (Intel Atom N270) there is no
difference between 3.3 and 3.4, but both are slightly better than
2.7. (To exclude possible cache issues I made a blank run before
first test run.) Probably some arch-dependent optimizations.

What surprises me most is that profiling overhead is huge (~105%)
compared to overhead on desktop (~35%). CPU speeds are not that
different, instruction sets too (Atom has sse2, sse3, ssse3, but
lacks 3dnow, 3dnowext). L2 cache is the same (512КB), but L1
differs significantly: 64 KB data/64 KB instruction cache vs 24 KB
data/32 KB instruction cache. Look like this is the reason.

Best regards,
Andrew Savchenko

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Zac Medico-2
In reply to this post by Andrew Savchenko
On 11/19/2014 11:59 AM, Andrew Savchenko wrote:

> Hello,
>
> On Mon, 17 Nov 2014 21:55:48 -0800 Zac Medico wrote:
>> On 11/17/2014 09:47 PM, Andrew Savchenko wrote:
>>> I use 2.2.14 on both hosts (and usually latest ~x86 portage is
>>> there). I thought that running fixpackages should be enough to run
>>> emerge with --dynamic-deps=n.
>>
>> It depends on how badly the installed deps have diverged from the
>> corresponding ebuilds in the tree.
>
> I tried fixpackages. It fixed some problems and looks like
> dependencies resolution became faster. But not all problems are
> fixed and I can't use --dynamic-deps n on both systems for now;
> and emerge @changed-deps fails due to numerous conflicts, blocks,
> unsatisfied deps (this is not surprising, since it doesn't try to
> update all packages in tree).
>
> By the way, is there any way to unroll conflict lists in portage
> output? I mean if I have following:
>
>   (dev-lang/ghc-7.6.3-r1:0/7.6.3::gentoo, installed) pulled in by
>     >=dev-lang/ghc-6.8.2:0/7.6.3= required by (dev-haskell/random-1.0.1.1-r1:0/1.0.1.1::gentoo, installed)
> ^^^^^^^^^
>     (and 68 more with the same problem)
>
> How can I see all list of these 68 packages? Sometimes this feature is
> really desired, e.g. if I don't want to update all @world but need to
> apply GLSA fix which leads to similar conflicts. I can't find any
> switch in emerge manual.

There's currently no switch for this. However, you can use a a command
like this to see all installed packages that pull in your installed ghc:

        emerge -pv --depclean dev-lang/ghc

I've filed a feature request bug for the switch that you have requested:

        https://bugs.gentoo.org/show_bug.cgi?id=529988

> As for hitomi box, it is both slower and have much older packages,
> so I'm still struggling to fix conflicts and other issues. Results
> will be available later.

From your results, it seems that _select_pkg_highest_available would be
an obvious thing to optimize. This method already uses memoization, but
the cache is entirely discarded each time that a package is added to the
graph. I will see about making it salvage as much cache as possible when
a package is added.

> P.S. Note for those who would like to use gpro2dot: it should be
> run with the same python interpreter active as was used during
> pstats data collection, otherwise it will fail to process data.
> I spent some time while figuring this out.

I wasn't aware of that, so thanks for the tip.
--
Thanks,
Zac

Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Zac Medico-2
On 11/20/2014 12:19 PM, Zac Medico wrote:

> On 11/19/2014 11:59 AM, Andrew Savchenko wrote:
>> Hello,
>>
>> On Mon, 17 Nov 2014 21:55:48 -0800 Zac Medico wrote:
>>> On 11/17/2014 09:47 PM, Andrew Savchenko wrote:
>>>> I use 2.2.14 on both hosts (and usually latest ~x86 portage is
>>>> there). I thought that running fixpackages should be enough to run
>>>> emerge with --dynamic-deps=n.
>>>
>>> It depends on how badly the installed deps have diverged from the
>>> corresponding ebuilds in the tree.
>>
>> I tried fixpackages. It fixed some problems and looks like
>> dependencies resolution became faster. But not all problems are
>> fixed and I can't use --dynamic-deps n on both systems for now;
>> and emerge @changed-deps fails due to numerous conflicts, blocks,
>> unsatisfied deps (this is not surprising, since it doesn't try to
>> update all packages in tree).
>>
>> By the way, is there any way to unroll conflict lists in portage
>> output? I mean if I have following:
>>
>>   (dev-lang/ghc-7.6.3-r1:0/7.6.3::gentoo, installed) pulled in by
>>     >=dev-lang/ghc-6.8.2:0/7.6.3= required by (dev-haskell/random-1.0.1.1-r1:0/1.0.1.1::gentoo, installed)
>> ^^^^^^^^^
>>     (and 68 more with the same problem)
>>
>> How can I see all list of these 68 packages? Sometimes this feature is
>> really desired, e.g. if I don't want to update all @world but need to
>> apply GLSA fix which leads to similar conflicts. I can't find any
>> switch in emerge manual.
>
> There's currently no switch for this. However, you can use a a command
> like this to see all installed packages that pull in your installed ghc:
>
> emerge -pv --depclean dev-lang/ghc
>
> I've filed a feature request bug for the switch that you have requested:
>
> https://bugs.gentoo.org/show_bug.cgi?id=529988

I forgot, we have a --verbose-conflicts option already.

>> As for hitomi box, it is both slower and have much older packages,
>> so I'm still struggling to fix conflicts and other issues. Results
>> will be available later.
>
> From your results, it seems that _select_pkg_highest_available would be
> an obvious thing to optimize. This method already uses memoization, but
> the cache is entirely discarded each time that a package is added to the
> graph. I will see about making it salvage as much cache as possible when
> a package is added.

I've written a patch, and it gives good results. On one of my computers
with this patch, 'emerge -puvDN @world' takes 15% less time, and results
in 58% fewer _select_pkg_highest_available_imp calls:

        https://bugs.gentoo.org/show_bug.cgi?id=530010
--
Thanks,
Zac

Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Andrew Savchenko
Hi,

On Thu, 20 Nov 2014 20:16:09 -0800 Zac Medico wrote:

> > There's currently no switch for this. However, you can use a a command
> > like this to see all installed packages that pull in your installed ghc:
> >
> > emerge -pv --depclean dev-lang/ghc
> >
> > I've filed a feature request bug for the switch that you have requested:
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=529988
>
> I forgot, we have a --verbose-conflicts option already.
Yeah, that's exactly what I need. Somehow I missed this option,
sorry.
 

> > From your results, it seems that _select_pkg_highest_available would be
> > an obvious thing to optimize. This method already uses memoization, but
> > the cache is entirely discarded each time that a package is added to the
> > graph. I will see about making it salvage as much cache as possible when
> > a package is added.
>
> I've written a patch, and it gives good results. On one of my computers
> with this patch, 'emerge -puvDN @world' takes 15% less time, and results
> in 58% fewer _select_pkg_highest_available_imp calls:
>
> https://bugs.gentoo.org/show_bug.cgi?id=530010
I've done some profiling with this both patches (from bugs 529660
and 530010) applied. See *p530010*.pdf files for both hosts here:
ftp://brunestud.info/gentoo/portage-v4.tar.xz

For performance enhancement I get the following data for
normal (that is unprofiled) runs:
        time calls
desktop 13% 62%
hitomi 6% 62%

where time — is % less real time for emerge run and calls stands
for % less _select_pkg_highest_available_imp calls.

While testing --verbose-conflicts I found that if tree contains
unresolved conflict, it takes much longer time for emerge to
proceed: +36% on desktop and +44% on hitomi.

Unresolved conflict was created by adding apt-text/dvipdfmx to the
@world: it blocks latex-2014 update. (Actually I just reverted one
of fixes I made earlier in order to run -DNupv @world without
errors .) Looks like emerge tries to build more depgraps to solves
this issue. I'm not sure if this may be a subject for optimization.
Graps are also present in the tarball in "*@world_with_blocks*.pdf"
files.

And thank your for optimizations! They really give a new breath to
my old boxes. Awaiting for them upstream :)

Best regards,
Andrew Savchenko

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Zac Medico-2
On 11/23/2014 05:50 PM, Andrew Savchenko wrote:

> I've done some profiling with this both patches (from bugs 529660
> and 530010) applied. See *p530010*.pdf files for both hosts here:
> ftp://brunestud.info/gentoo/portage-v4.tar.xz
>
> For performance enhancement I get the following data for
> normal (that is unprofiled) runs:
> time calls
> desktop 13% 62%
> hitomi 6% 62%
>
> where time — is % less real time for emerge run and calls stands
> for % less _select_pkg_highest_available_imp calls.
>
> While testing --verbose-conflicts I found that if tree contains
> unresolved conflict, it takes much longer time for emerge to
> proceed: +36% on desktop and +44% on hitomi.
>
> Unresolved conflict was created by adding apt-text/dvipdfmx to the
> @world: it blocks latex-2014 update. (Actually I just reverted one
> of fixes I made earlier in order to run -DNupv @world without
> errors .) Looks like emerge tries to build more depgraps to solves
> this issue.

This is controlled by the --backtrack option (10 is default). That means
it can create up to 10 depgraphs before it aborts. On a slow computer,
you might consider putting --backtrack=1 in EMERGE_DEFAULT_OPTS. That
way, it won't waist so mush time searching for a solution before it
ultimately fails. Note that you need at least --backtrack=1 for EAPI 5
sub-slot rebuilds to work.

> I'm not sure if this may be a subject for optimization.

Yes, there are many possible ways to optimize it. Heuristics can be used
to recognize various kinds of solvable conflicts and solve them more
efficiently. For example, the code in this commit added support for
solving some slot conflicts without backtracking:

https://github.com/gentoo/portage/commit/a862cc5dd1a56114fa579c5fb01b518b243666d9

> Graps are also present in the tarball in "*@world_with_blocks*.pdf"
> files.

Unfortunately, I don't see anything else that's easily optimized by
memoization. Further optimization will require more heuristics as
mentioned above.

> And thank your for optimizations! They really give a new breath to
> my old boxes. Awaiting for them upstream :)

You're welcome. Thanks for collecting the data.
--
Thanks,
Zac

Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Alexander Berntsen-2
In reply to this post by Andrew Savchenko
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 24/11/14 02:50, Andrew Savchenko wrote:
> On Thu, 20 Nov 2014 20:16:09 -0800 Zac Medico wrote:
>>> I forgot, we have a --verbose-conflicts option already.
> Yeah, that's exactly what I need. Somehow I missed this option,
> sorry.
That's OK. I forgot about it too. And I wrote it. :-]

- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlRy4RoACgkQRtClrXBQc7XWYAEAhnmSUuhmAIO5coaEBPyqp/VH
GwrWo7ZsvLUdUVEjfgcBAJESgR5qsUULpqdAhQOcWek1Uhny9Y83hROjAc1hKq+E
=Yvs5
-----END PGP SIGNATURE-----

yac
Reply | Threaded
Open this post in threaded view
|

Re: Regarding my final year thesis

yac
In reply to this post by Luca Barbato
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, 07 Nov 2014 10:49:13 +0100
Luca Barbato <[hidden email]> wrote:

> On 07/11/14 06:06, Harsh Bhatt wrote:
>
> Also make might enjoy improvements.

shake?



- --
Jan Matějka        | Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCgAGBQJUuUqnAAoJEIN+7RD5ejahNwMH/R2OruTRy0yi4cwKFhPGqVZv
SKVLp5jNGkY9pTFnMApuqqh53Tb4OW3uDO99wpkzpyzzr0wgarGFg1N6YAMkRf+g
3Vy+WvDrK6zQeu0IYq1VBMODSun6fgWUsNiEBgqYbDPqa/SmfTAGhIF3dt5HH6Gx
J6T2SVFjjPFN+6LtWxVHph3G6/zSvKlHXKevqr4Po7PqnMXDnDBJ24LreNPVV0Aw
9G2lzT8/yuIvTF1x8FMinqOAWlp3CXYcfhizdYaFmMb7ROGZZFZJISx4L4GhkEK+
ojW457sX20Payc3GnY0O6yT29FDAf+1HQEhpEW2WEQ2hdP1lovtAiq+qyJnubrA=
=lB3d
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Regarding my final year thesis

Luca Barbato
On 16/01/15 18:30, Jan Matejka wrote:
> On Fri, 07 Nov 2014 10:49:13 +0100
> Luca Barbato <[hidden email]> wrote:
>
>> On 07/11/14 06:06, Harsh Bhatt wrote:
>
>> Also make might enjoy improvements.
>
> shake?

Anything written in haskell tend to be impractical to deploy.

tup managed to get lots of great ideas spoiled by being impractically
extremist in tracking the directory changes.

lu

yac
Reply | Threaded
Open this post in threaded view
|

Re: Regarding my final year thesis

yac
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, 16 Jan 2015 21:00:24 +0100
Luca Barbato <[hidden email]> wrote:

> On 16/01/15 18:30, Jan Matejka wrote:
> > On Fri, 07 Nov 2014 10:49:13 +0100
> > Luca Barbato <[hidden email]> wrote:
> >
> >> On 07/11/14 06:06, Harsh Bhatt wrote:
> >
> >> Also make might enjoy improvements.
> >
> > shake?
>
> Anything written in haskell tend to be impractical to deploy.

http://code.haskell.org/~dons/talks/dons-google-2015-01-27.pdf

> tup managed to get lots of great ideas spoiled by being impractically
> extremist in tracking the directory changes.

I don't know what tup is but I'm guessing it's an application.

Are you judging a language to be impractical because one
application made (allegedly) a bad design decision?


- --
Jan Matějka        | Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCgAGBQJUz7MtAAoJEIN+7RD5ejahmuoH/1CYfKRdrgtcms2U1Rcio2HQ
oJsDY+5SZerGSJrnnohd7l/FHbxcA51H04IUws22GlJ7OnIlVRD/IuYlAyLogc9m
bvg/Tt/OuRavHqdhi5JmJfQqYUVZJiEBQok5jG9Aa6+0+d1rPYzUQFsbNQ4ywO12
LLdVATR/2ovrEgVNmgUJQlfeZy6Axo3MwHbBRjsoi+2eKlSVBwKmAQMvpifLr5bI
8l2hOa7CGis02uWa8t8JixZ3XSkqrcjExGQYcBbWdCYVulfXgUbz0pNkQipOCOh+
+bNzubNDOGMSyiJ1mmtRG46vEKhgefns+IvxEhiOIIeJajPJR+R3EU0cV2LAvD0=
=+ORA
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Regarding my final year thesis

hasufell
Jan Matejka:

> On Fri, 16 Jan 2015 21:00:24 +0100
> Luca Barbato <[hidden email]> wrote:
>
>> On 16/01/15 18:30, Jan Matejka wrote:
>>> On Fri, 07 Nov 2014 10:49:13 +0100
>>> Luca Barbato <[hidden email]> wrote:
>>>
>>>> On 07/11/14 06:06, Harsh Bhatt wrote:
>>>
>>>> Also make might enjoy improvements.
>>>
>>> shake?
>
>> Anything written in haskell tend to be impractical to deploy.
>
> http://code.haskell.org/~dons/talks/dons-google-2015-01-27.pdf
>

Yep, I too think that statement above is incorrect.

Also have a look at https://wiki.haskell.org/Haskell_in_industry

Microsoft, Google, Facebook, Nvidia...

Reply | Threaded
Open this post in threaded view
|

Re: Regarding my final year thesis

Alexander Berntsen-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/02/15 19:01, hasufell wrote:

> Jan Matejka:
>> On Fri, 16 Jan 2015 21:00:24 +0100 Luca Barbato
>> <[hidden email]> wrote:
>>> Anything written in haskell tend to be impractical to deploy.
>>
>> http://code.haskell.org/~dons/talks/dons-google-2015-01-27.pdf
>>
>
> Yep, I too think that statement above is incorrect.
>
> Also have a look at https://wiki.haskell.org/Haskell_in_industry
>
> Microsoft, Google, Facebook, Nvidia...
As someone who deploys things in Haskell, I would have to disagree
with the original comment as well.
- --
Alexander
[hidden email]
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlTU7SgACgkQRtClrXBQc7XsTAD/S8QuDfjokcbNU7b5k/vovYOD
hJhSb97gDLI2I+cTv3gA/1gLO5cbVePebqI0NafJs6tFrr8gZ46/Plb0nVwNJSfz
=UCwp
-----END PGP SIGNATURE-----

1234