[Haskell-cafe] CPU with Haskell support
Thomas Bereknyei
tomberek at gmail.com
Wed Jan 20 12:20:11 UTC 2016
There is a CPU being design with an interesting architecture. Take a look
at the Mill CPU at millcomputing.com.
A facsinating feature is the use of a belt of values vs registers. The
values on the belt are immutable and fall off (~auto gc'd?) unless
expressly saved or returned.
It is also desined to make function calls very cheap.
tomberek
On Jan 20, 2016 3:49 AM, <haskell-cafe-request at haskell.org> wrote:
Send Haskell-Cafe mailing list submissions to
haskell-cafe at haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
or, via email, send a message with subject or body 'help' to
haskell-cafe-request at haskell.org
You can reach the person managing the list at
haskell-cafe-owner at haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Haskell-Cafe digest..."
Today's Topics:
1. Re: Doc generation? (Patrick Redmond)
2. Re: Doc generation? (Mark Fine)
3. Host-Oriented Template Haskell (Ericson, John)
4. [ANN] ghc-mod-5.5.0.0: Happy Haskell Hacking (Daniel Gr?ber)
5. CPU with Haskell support (Henning Thielemann)
6. Re: Doc generation? (Noon Silk)
7. Re: Doc generation? (Mikhail Glushenkov)
8. Re: CPU with Haskell support (Auke Booij)
9. Re: CPU with Haskell support (Darren Grant)
10. Re: CPU with Haskell support (Henning Thielemann)
11. Re: CPU with Haskell support (Ben Lippmeier)
12. Re: CPU with Haskell support (Richard A. O'Keefe)
13. Re: CPU with Haskell support (Gleb Popov)
14. Re: Doc generation? (Sven Panne)
15. Re: Doc generation? (Mikhail Glushenkov)
16. Re: CPU with Haskell support (Joachim Durchholz)
17. Re: Doc generation? (Sven Panne)
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Jan 2016 08:39:20 -0800
From: Patrick Redmond <plredmond at gmail.com>
To: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
"haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] Doc generation?
Message-ID:
<CAHUea4Ht0p8=HwphL+--V7j3Xftt=8drrZDuOQtcB38rPPkJ2w at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I don't know what's happening with hackage, but if you're using stack in
your workflow a simple workaround is to build docs locally and search them
with a shell script. For example:
$ stack haddock async
And then muck around in .stack-work or ~/.stack. I've written a
bash/fish script to do the search for you here:
plredmond.github.io/posts/search-haddocks-offline.html
On Tuesday, January 19, 2016, Francesco Ariis <fa-ml at ariis.it> wrote:
> On Tue, Jan 19, 2016 at 04:24:24PM +1100, Noon Silk wrote:
> > Does anyone know what is happening here?
> >
> > Not a single one of the packages on
> > http://hackage.haskell.org/packages/recent has docs generated at the
> moment.
> >
> > Some older ones, upload this year, also do not -
> > http://hackage.haskell.org/package/pipes-concurrency
>
> Docs not being built can be quite frustrating; for those dark times I
> build them locally:
>
> http://ariis.it/static/articles/no-docs-hackage/page.html
>
> Living with a flaky WiFi, saves me from screaming at the monitor quite
> some times.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org <javascript:;>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/517bfc2f/attachment-0001.html
>
------------------------------
Message: 2
Date: Tue, 19 Jan 2016 09:51:40 -0800
From: Mark Fine <mark.fine at gmail.com>
To: Patrick Redmond <plredmond at gmail.com>
Cc: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
"haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] Doc generation?
Message-ID:
<CANRZ_fkC4-wM8-UyzeQEFJiiUZ02qo22CHdhfUt68wQeaRX8UA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Also, if the packages are on stackage, you can look at the documentation
there:
https://www.stackage.org/package/pipes-concurrency
Mark
On Tue, Jan 19, 2016 at 8:39 AM, Patrick Redmond <plredmond at gmail.com>
wrote:
> I don't know what's happening with hackage, but if you're using stack in
> your workflow a simple workaround is to build docs locally and search them
> with a shell script. For example:
>
> $ stack haddock async
>
> And then muck around in .stack-work or ~/.stack. I've written a
> bash/fish script to do the search for you here:
> plredmond.github.io/posts/search-haddocks-offline.html
>
> On Tuesday, January 19, 2016, Francesco Ariis <fa-ml at ariis.it> wrote:
>
>> On Tue, Jan 19, 2016 at 04:24:24PM +1100, Noon Silk wrote:
>> > Does anyone know what is happening here?
>> >
>> > Not a single one of the packages on
>> > http://hackage.haskell.org/packages/recent has docs generated at the
>> moment.
>> >
>> > Some older ones, upload this year, also do not -
>> > http://hackage.haskell.org/package/pipes-concurrency
>>
>> Docs not being built can be quite frustrating; for those dark times I
>> build them locally:
>>
>> http://ariis.it/static/articles/no-docs-hackage/page.html
>>
>> Living with a flaky WiFi, saves me from screaming at the monitor quite
>> some times.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/c6010b86/attachment-0001.html
>
------------------------------
Message: 3
Date: Tue, 19 Jan 2016 13:17:02 -0800
From: "Ericson, John" <john_ericson at brown.edu>
To: Haskell-Cafe <haskell-cafe at haskell.org>
Subject: [Haskell-cafe] Host-Oriented Template Haskell
Message-ID:
<CA+Vhx4TF0x5-XrKi09A36xVww2HyWr0J3QysqJYdJbKDU3dhDw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
As is well known, TH and cross-compiling do not get along. There are
various proposals on how to make this interaction less annoying, and I
am not against them. But as I see it, the problem is largely inherent
to the design of TH itself: since values can (usually) be lifted from
compile-time to run-time, and normal definitions from upstream modules
to downstream modules' TH, TH and normal code must "live in the same
world".
Now this restriction in turn bequeaths TH with much expressive power,
and I wouldn't advocate getting rid of it. But many tasks do not need
it, and in some cases, say in bootstrapping compilers[1] themselves,
it is impossible to use TH because of it, even were all the current
proposals implemented.
For these reason, I propose a new TH variant which has much harsher
phase separation. Normal definitions from upstream modules can not be
used, lifting values is either not permitted or is allowed to fail
(because of missing/incompatible definitions), and IO is defined to
match the behavior of the host, not target, platform (in the cross
compiling case). The only interaction between the two phases is that
quoted syntax is resolved against the the run-time phase's definitions
(just like today).
Some of you may find this a shoddy substitute for defining a subset of
Haskell which behaves identically on all platforms, and optionally
constraining TH to it. But the big feature that my proposal offers and
that one doesn't is to be able to independently specify compile-time
dependencies for the host-oriented TH---this is analogous to the
newish `Setup.hs` dependencies. That in turns leads to what I think is
the "killer app" for Host-Oriented TH: exposing the various
prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries,
and side-stepping any need for "executable dependencies" in Cabal.
Note also that at least hsc2hs additionally requires host-IO---there
may not even exist a C compiler on the target platform at all.
Finally, forgive me if this has been brought up before. I've been
thinking about this a while, and did a final pass over the GHC wiki to
make sure it wasn't already proposed, but I could have missed
something (this is also my first post to the list).
John
[1]:
https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs
------------------------------
Message: 4
Date: Tue, 19 Jan 2016 22:19:48 +0100
From: Daniel Gr?ber <dxld at darkboxed.org>
To: haskell-cafe at haskell.org
Subject: [Haskell-cafe] [ANN] ghc-mod-5.5.0.0: Happy Haskell Hacking
Message-ID: <20160119211948.GA16744 at grml>
Content-Type: text/plain; charset="us-ascii"
I'm pleased to announce the release of ghc-mod 5.5.0.0!
This is primarily a maintenance and bug fix release. We are releasing this
as a
major version bump as we are following a policy of not trying to keep API
compatibility until v6.0 to enable us to clean up ghc-mod's internals and
API.
What's new?
===========
* Cabal flags are now preserved across automatic reconfigurations
When ghc-mod detects something influencing the cabal configuration has
changed
since the last invocation it will automatically reconfigure the
project. Previously this would call 'cabal configure' without any
additional
options thus possibly reverting flags the user might have added to the
configure command previously. Now we extract the current set of flags
from the
existing configuration and pass the appropriate options to the configure
command.
* Rewritten command-line parser (again)
The home grown sub-command parser based on getopt has been a user
experience
disaster so we've replaced it using a new optparse-applicative based
parser.
This does have the unfortunate side effect that we had to remove support
for
some optional arguments we had supported previously thus breaking
compatibility with very old frontends.
* Remove CWD requirement from command-line tools
In v5.4.0.0 we had to add a workaround for a nasty race condition in
'ghc-mod
legacy-interactive' (ghc-modi) which added a requirement that all ghc-mod
command line tools are run in the root of each project's directory. This
limitation has now been removed. Frontends which have implemented this
workaround should be compatible going forward but for performance reasons
it
is advisable to disable the workaround for versions after v5.5.0.0.
* Various bug fixes and smaller improvements
From the change log:
* Fix cabal-helper errors when no global GHC is installed (Stack)
* Support for spaces in file names when using legacy-interactive
* Fix "No instance nor default method for class operation put"
* Fix a variety of caching related issues
* Emacs: Fix slowdown and bugs caused by excessive use of `map-file`
* Emacs: Add ghc-report-errors to inhibit *GHC Error* logging
What is ghc-mod?
================
ghc-mod is both a back-end program for enhancing editors and other kinds of
development environments with support for Haskell and a library for
abstracting
the black magic incantations required to use the GHC API in various
environments, especially Cabal and Stack projects. The library is used by
ambitious projects like HaRe[1], mote[2] and haskell-ide-engine[3]
Getting ghc-mod
===============
GitHub: https://github.com/DanielG/ghc-mod
Hackage: http://hackage.haskell.org/package/ghc-mod
Editor frontends:
- Emacs (native):
https://github.com/DanielG/ghc-mod
https://github.com/iquiw/company-ghc
- Vim:
https://github.com/eagletmt/ghcmod-vim
https://github.com/eagletmt/neco-ghc
- Atom:
https://github.com/atom-haskell/ide-haskell
Known issues
============
For issues other than the ones mentioned below visit our issue tracker:
https://github.com/DanielG/ghc-mod/issues
Frequently reported issues
--------------------------
ghc-mod once compiled is bound to one version of GHC since we link against
the
GHC API library. This used to not be a very big problem but since Stack
made it
exceedingly easy for users to use more than one version of GHC without even
knowing the number of problems in this area has exploded. We are tracing the
issue in the following issue: https://github.com/DanielG/ghc-mod/issues/615
(Support switching GHC versions without recompiling ghc-mod)
ghc-mod's `case`, `sig` and `refine` commands still do not work properly
with
GHC>7.10 (See https://github.com/DanielG/ghc-mod/issues/438). Unless
someone volunteers to fix this issue I will work towards replacing the
features
using mote[2] instead as the current code is, from my point of view,
unmaintainable.
If you do notice any other problems please report them:
https://github.com/DanielG/ghc-mod/issues/new
----
[1]: https://github.com/alanz/HaRe
[2]: https://github.com/imeckler/mote
[3]: https://github.com/haskell/haskell-ide-engine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <
http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/9fea4144/attachment-0001.sig
>
------------------------------
Message: 5
Date: Tue, 19 Jan 2016 23:12:02 +0100 (CET)
From: Henning Thielemann <lemming at henning-thielemann.de>
To: Haskell Cafe <haskell-cafe at haskell.org>
Subject: [Haskell-cafe] CPU with Haskell support
Message-ID: <alpine.DEB.2.02.1601192250000.16459 at sputnik>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Hi all,
every now and then I think it would be cool to have a microprocessor that
supports Haskell in a way. A processor where lazy evaluation is not
overhead but an optimization opportunity, a processor that can make use of
the explicit data dependencies in Haskell programs in order to utilize
many computation units in parallel. I know of the Reduceron project, which
evolves only slowly and if it somewhen is ready for use it is uncertain
whether it can compete with stock CPUs since FPGA's need much more chip
space for the same logic.
I got to know that in todays x86 processors you can alter the instruction
set, which is mainly used for bugfixes. Wouldn't it be interesting to add
some instructions for Haskell support? However, I suspect that such a
patch might be rendered invalid by new processor generations with changed
internal details. Fortunately, there are processors that are designed for
custom instruction set extensions:
https://en.wikipedia.org/wiki/Xtensa
Would it be sensible to create a processor based on such a design? I have
no idea what it might cost, and you would still need some peripheral
circuitry to run it. What could processor instructions for Haskell support
look like? Has anyone already thought in this direction?
------------------------------
Message: 6
Date: Wed, 20 Jan 2016 09:37:26 +1100
From: Noon Silk <noonslists at gmail.com>
To: Mark Fine <mark.fine at gmail.com>
Cc: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
"haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] Doc generation?
Message-ID:
<CADt_azZv_w+nFgQiOrRVGucKV7Wf4h-Y7YjVfO=pMc_QqhFjXw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Mark and All,
Indeed, I've been generating the docs myself offline; I didn't know about
looking for the docs on stackage; thanks!
--
Noon
On Wed, Jan 20, 2016 at 4:51 AM, Mark Fine <mark.fine at gmail.com> wrote:
> Also, if the packages are on stackage, you can look at the documentation
> there:
>
> https://www.stackage.org/package/pipes-concurrency
>
> Mark
>
> On Tue, Jan 19, 2016 at 8:39 AM, Patrick Redmond <plredmond at gmail.com>
> wrote:
>
>> I don't know what's happening with hackage, but if you're using stack in
>> your workflow a simple workaround is to build docs locally and search
them
>> with a shell script. For example:
>>
>> $ stack haddock async
>>
>> And then muck around in .stack-work or ~/.stack. I've written a
>> bash/fish script to do the search for you here:
>> plredmond.github.io/posts/search-haddocks-offline.html
>>
>> On Tuesday, January 19, 2016, Francesco Ariis <fa-ml at ariis.it> wrote:
>>
>>> On Tue, Jan 19, 2016 at 04:24:24PM +1100, Noon Silk wrote:
>>> > Does anyone know what is happening here?
>>> >
>>> > Not a single one of the packages on
>>> > http://hackage.haskell.org/packages/recent has docs generated at the
>>> moment.
>>> >
>>> > Some older ones, upload this year, also do not -
>>> > http://hackage.haskell.org/package/pipes-concurrency
>>>
>>> Docs not being built can be quite frustrating; for those dark times I
>>> build them locally:
>>>
>>> http://ariis.it/static/articles/no-docs-hackage/page.html
>>>
>>> Living with a flaky WiFi, saves me from screaming at the monitor quite
>>> some times.
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
--
Noon Silk, ?
https://silky.github.io/
"Every morning when I wake up, I experience an exquisite joy ? the joy
of being this signature."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/f8298446/attachment-0001.html
>
------------------------------
Message: 7
Date: Tue, 19 Jan 2016 23:40:31 +0100
From: Mikhail Glushenkov <mikhail.glushenkov at gmail.com>
To: Noon Silk <noonslists at gmail.com>
Cc: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
"haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] Doc generation?
Message-ID:
<CA+tcxkC7EZdeL6jFK7bA4=oARD+WCsgctKUqyJ9yMEyV7z1O-Q at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi *,
On 19 January 2016 at 23:37, Noon Silk <noonslists at gmail.com> wrote:
> Thanks Mark and All,
>
> Indeed, I've been generating the docs myself offline; I didn't know
about
> looking for the docs on stackage; thanks!
Note that with the Git version of cabal-install you can run 'cabal
upload --doc' to upload the docs to Hackage manually.
------------------------------
Message: 8
Date: Tue, 19 Jan 2016 22:44:26 +0000
From: Auke Booij <auke at tulcod.com>
To: Henning Thielemann <lemming at henning-thielemann.de>
Cc: Haskell Cafe <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] CPU with Haskell support
Message-ID:
<CAP6YhL+GkGDjQSQuBE0HcrL8R6MAibSKRWu7jAR5Or8uwbDKfA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
This question is much more involved than you seem to be suggesting.
It's not just about adding "some instructions for Haskell support".
You have to think about how you want to express /every/ haskell term
as a series of bits (preferably predictably many bits), and find a
(finite) combination of logical gates to do arbitrary computations
with them.
If you want to go anywhere in this directions, perhaps a good start
would be implementing a processor with instructions for (untyped)
lambda calculus. One approach for this could be to take a
(mathematical) model of lambda calculus and see how its elements can
be represented as natural numbers.
This implementation, I suspect, would be terribly inefficient. Think
about what the lambda application gate would look like in terms of
NAND gates. Yes, it can probably be done in theory. No, it won't be
pretty. And forget about practical.
Finally, a major advantage of having such "raw" language as an
instruction set is that it allows many many optimizations (e.g.
pipelining (which, I would say, is the single most important reason
that processors are able to run at GHzs instead of MHzs (Pentium 4
processors, famed for their high clock speed, had 31 pipeline
stages))) that I cannot imagine being possible in anything close to a
"lambda calculus processor".
What is the added value you hope to achieve?
On 19 January 2016 at 22:12, Henning Thielemann
<lemming at henning-thielemann.de> wrote:
>
> Hi all,
>
> every now and then I think it would be cool to have a microprocessor that
> supports Haskell in a way. A processor where lazy evaluation is not
overhead
> but an optimization opportunity, a processor that can make use of the
> explicit data dependencies in Haskell programs in order to utilize many
> computation units in parallel. I know of the Reduceron project, which
> evolves only slowly and if it somewhen is ready for use it is uncertain
> whether it can compete with stock CPUs since FPGA's need much more chip
> space for the same logic.
>
> I got to know that in todays x86 processors you can alter the instruction
> set, which is mainly used for bugfixes. Wouldn't it be interesting to add
> some instructions for Haskell support? However, I suspect that such a
patch
> might be rendered invalid by new processor generations with changed
internal
> details. Fortunately, there are processors that are designed for custom
> instruction set extensions:
> https://en.wikipedia.org/wiki/Xtensa
>
> Would it be sensible to create a processor based on such a design? I have
no
> idea what it might cost, and you would still need some peripheral
circuitry
> to run it. What could processor instructions for Haskell support look
like?
> Has anyone already thought in this direction?
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
------------------------------
Message: 9
Date: Tue, 19 Jan 2016 15:00:12 -0800
From: Darren Grant <dedgrant at gmail.com>
To: Auke Booij <auke at tulcod.com>
Cc: Henning Thielemann <lemming at henning-thielemann.de>, Haskell Cafe
<haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] CPU with Haskell support
Message-ID:
<CA+9vpFcay+6h97CqG+PBoVTjuEREfMCX5hkkXsqpdG4i=NxGBg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Limiting the scope for my own sanity here, there may yet be some
application in various hardware level emulations of continuation passing
calculi, perhaps building on static single assignment.
It might be possoble to derive an interesting instruction set from the
sorts of intermediate representations we see in compiler infrastructures
like LLVM, but it is hard to guess how these hardware designs would benefit
haskell, rather than the other way around.
Cheers,
Darren
On Jan 19, 2016 14:44, "Auke Booij" <auke at tulcod.com> wrote:
> This question is much more involved than you seem to be suggesting.
> It's not just about adding "some instructions for Haskell support".
> You have to think about how you want to express /every/ haskell term
> as a series of bits (preferably predictably many bits), and find a
> (finite) combination of logical gates to do arbitrary computations
> with them.
>
> If you want to go anywhere in this directions, perhaps a good start
> would be implementing a processor with instructions for (untyped)
> lambda calculus. One approach for this could be to take a
> (mathematical) model of lambda calculus and see how its elements can
> be represented as natural numbers.
>
> This implementation, I suspect, would be terribly inefficient. Think
> about what the lambda application gate would look like in terms of
> NAND gates. Yes, it can probably be done in theory. No, it won't be
> pretty. And forget about practical.
>
> Finally, a major advantage of having such "raw" language as an
> instruction set is that it allows many many optimizations (e.g.
> pipelining (which, I would say, is the single most important reason
> that processors are able to run at GHzs instead of MHzs (Pentium 4
> processors, famed for their high clock speed, had 31 pipeline
> stages))) that I cannot imagine being possible in anything close to a
> "lambda calculus processor".
>
> What is the added value you hope to achieve?
>
> On 19 January 2016 at 22:12, Henning Thielemann
> <lemming at henning-thielemann.de> wrote:
> >
> > Hi all,
> >
> > every now and then I think it would be cool to have a microprocessor
that
> > supports Haskell in a way. A processor where lazy evaluation is not
> overhead
> > but an optimization opportunity, a processor that can make use of the
> > explicit data dependencies in Haskell programs in order to utilize many
> > computation units in parallel. I know of the Reduceron project, which
> > evolves only slowly and if it somewhen is ready for use it is uncertain
> > whether it can compete with stock CPUs since FPGA's need much more chip
> > space for the same logic.
> >
> > I got to know that in todays x86 processors you can alter the
instruction
> > set, which is mainly used for bugfixes. Wouldn't it be interesting to
add
> > some instructions for Haskell support? However, I suspect that such a
> patch
> > might be rendered invalid by new processor generations with changed
> internal
> > details. Fortunately, there are processors that are designed for custom
> > instruction set extensions:
> > https://en.wikipedia.org/wiki/Xtensa
> >
> > Would it be sensible to create a processor based on such a design? I
> have no
> > idea what it might cost, and you would still need some peripheral
> circuitry
> > to run it. What could processor instructions for Haskell support look
> like?
> > Has anyone already thought in this direction?
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/58412564/attachment-0001.html
>
------------------------------
Message: 10
Date: Wed, 20 Jan 2016 00:03:06 +0100 (CET)
From: Henning Thielemann <lemming at henning-thielemann.de>
To: Auke Booij <auke at tulcod.com>
Cc: Haskell Cafe <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] CPU with Haskell support
Message-ID: <alpine.DEB.2.02.1601192357580.16459 at sputnik>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Tue, 19 Jan 2016, Auke Booij wrote:
> This question is much more involved than you seem to be suggesting.
> It's not just about adding "some instructions for Haskell support".
> You have to think about how you want to express /every/ haskell term
> as a series of bits (preferably predictably many bits), and find a
> (finite) combination of logical gates to do arbitrary computations
> with them.
I am not thinking about a radically different machine language, just a
common imperative machine language with some added instructions for tasks
often found in machine code generated from Haskell. E.g. mainstream
processors support C function calls with special jump instruction and
stack handling. Maybe there could be instructions that assist handling
thunks or Haskell function calls.
------------------------------
Message: 11
Date: Wed, 20 Jan 2016 11:52:21 +1100
From: Ben Lippmeier <benl at ouroborus.net>
To: Henning Thielemann <lemming at henning-thielemann.de>
Cc: Haskell Cafe <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] CPU with Haskell support
Message-ID: <3EAF442C-90D4-40BE-91CE-EB7AE3E6EAFC at ouroborus.net>
Content-Type: text/plain; charset="utf-8"
> On 20 Jan 2016, at 9:12 am, Henning Thielemann <
lemming at henning-thielemann.de> wrote:
> I got to know that in todays x86 processors you can alter the instruction
set, which is mainly used for bugfixes. Wouldn't it be interesting to add
some instructions for Haskell support? However, I suspect that such a patch
might be rendered invalid by new processor generations with changed
internal details. Fortunately, there are processors that are designed for
custom instruction set extensions:
> https://en.wikipedia.org/wiki/Xtensa
Your post assumes that the time to fetch/decode the instruction stream is a
bottleneck, and reducing the number of instructions will in some way make
the program faster.
Your typically lazy GHC compiled program spends much of its time building
thunks and otherwise copying data between the stack and the heap. If it?s
blocked waiting for data memory / data cache miss then reducing the number
of instructions won?t help anything ? at least if the fancy new
instructions just tell the processor to do something that would lead to
cache miss anyway.
See: Cache Performance of Lazy Functional Programs on Current Hardware
(from 2009)
Arbob Ahmad and Henry DeYoung
http://www.cs.cmu.edu/~hdeyoung/15740/report.pdf <
http://www.cs.cmu.edu/~hdeyoung/15740/report.pdf>
Indirect branches are also a problem (load an address from data memory,
then jump to it), as branch predictors usually cannot deal with them.
Slowdowns due to mispredicted branches could perhaps be mitigated by
improving the branch predictor in a Haskell specific way, but you might not
need new instructions to do so.
Or another way of putting it: ?If you tell a long story with less words,
then it?s still a long story.?
Ben.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/881d9bb6/attachment-0001.html
>
------------------------------
Message: 12
Date: Wed, 20 Jan 2016 18:16:49 +1300
From: "Richard A. O'Keefe" <ok at cs.otago.ac.nz>
To: Henning Thielemann <lemming at henning-thielemann.de>
Cc: Haskell Cafe <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] CPU with Haskell support
Message-ID: <A1E52B20-6AF7-4153-A040-97DC2837ED85 at cs.otago.ac.nz>
Content-Type: text/plain; charset="us-ascii"
On 20/01/2016, at 12:03 pm, Henning Thielemann <
lemming at henning-thielemann.de> wrote:
> I am not thinking about a radically different machine language, just a
common imperative machine language with some added instructions for tasks
often found in machine code generated from Haskell. E.g. mainstream
processors support C function calls with special jump instruction and stack
handling. Maybe there could be instructions that assist handling thunks or
Haskell function calls.
I was at a presentation once where the speaker showed how
(thanks to the fact that Prolog doesn't evaluate arguments
in calls) calling a procedure and executing the procedure
could be overlapped, getting a factor of 2 speedup for an
important part of the code. At another presentation a
speaker showed how using a special outboard coprocessor
could dramatically speed up memory management.
I suspect that neither technique would be much help on today's
machines and for Haskell. However, there is a hint here that
doing something quite different might pay off.
For example, if branch predictors don't do well with thunk
handling, maybe there is a way of processing thunks that a
quite different kind of branch predictor *might* cope with.
Or maybe something that's expecting to process thousands of
microthreads might not care about branch prediction. (Although
that idea has been tried as a way of handling memory latency,
I don't think it's been tried for Haskell.)
Perhaps you might look for something different; instead of
'faster on similar hardware' you might look at 'cheaper'.
Could a specialised Haskell processor use less energy than
a standard CPU?
Don't quit your day job, but don't be too sure there's nothing
left to think of either.
------------------------------
Message: 13
Date: Wed, 20 Jan 2016 10:05:48 +0300
From: Gleb Popov <6yearold at gmail.com>
To: Henning Thielemann <lemming at henning-thielemann.de>
Cc: Haskell Cafe <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] CPU with Haskell support
Message-ID:
<CALH631nuDoV_4kBkRWjZvNuZK59kJ6fV6A_hnAKGh9YYznHbSQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Wed, Jan 20, 2016 at 1:12 AM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:
>
> Hi all,
>
> every now and then I think it would be cool to have a microprocessor that
> supports Haskell in a way. A processor where lazy evaluation is not
> overhead but an optimization opportunity, a processor that can make use of
> the explicit data dependencies in Haskell programs in order to utilize
many
> computation units in parallel. I know of the Reduceron project, which
> evolves only slowly and if it somewhen is ready for use it is uncertain
> whether it can compete with stock CPUs since FPGA's need much more chip
> space for the same logic.
>
> I got to know that in todays x86 processors you can alter the instruction
> set, which is mainly used for bugfixes. Wouldn't it be interesting to add
> some instructions for Haskell support? However, I suspect that such a
patch
> might be rendered invalid by new processor generations with changed
> internal details. Fortunately, there are processors that are designed for
> custom instruction set extensions:
> https://en.wikipedia.org/wiki/Xtensa
>
> Would it be sensible to create a processor based on such a design? I have
> no idea what it might cost, and you would still need some peripheral
> circuitry to run it. What could processor instructions for Haskell support
> look like? Has anyone already thought in this direction?
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
I remember reading relevent paper: The Reduceron reconfigured and
re-evaluated. Authors are MATTHEW NAYLOR and COLIN RUNCIMAN.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/df0fdb6a/attachment-0001.html
>
------------------------------
Message: 14
Date: Wed, 20 Jan 2016 08:09:38 +0100
From: Sven Panne <svenpanne at gmail.com>
To: Mikhail Glushenkov <mikhail.glushenkov at gmail.com>
Cc: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
"haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] Doc generation?
Message-ID:
<CANBN=muZG_pSYHVyciMORC5nu0-y+ykhPdU-npLyCZ4J3srv3A at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
2016-01-19 23:40 GMT+01:00 Mikhail Glushenkov <mikhail.glushenkov at gmail.com>
:
> Note that with the Git version of cabal-install you can run 'cabal
> upload --doc' to upload the docs to Hackage manually.
>
Are there any safeguards on the Hackage server side to guarantee
consistency between the uploaded package and the uploaded docs? (i.e. make
sure it's the right version etc.) Are there checks on the server side that
the cross-package links are correct? Does the server make sure that the
docs contain source links?
If the answer to any of these questions is "no", I consider even the
possibility of uploading docs by hand a bug. Wrong/partial documentation is
worse than no documentation at all...
Cheers,
S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/621dacc2/attachment-0001.html
>
------------------------------
Message: 15
Date: Wed, 20 Jan 2016 08:35:02 +0100
From: Mikhail Glushenkov <mikhail.glushenkov at gmail.com>
To: Sven Panne <svenpanne at gmail.com>
Cc: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
"haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] Doc generation?
Message-ID:
<CA+tcxkDEk2pzTfGWuJ71KJuxY-ibwzOPwOvKhnoDu1Xe=u4q1Q at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
On 20 January 2016 at 08:09, Sven Panne <svenpanne at gmail.com> wrote:
> Are there any safeguards on the Hackage server side to guarantee
consistency
> between the uploaded package and the uploaded docs? (i.e. make sure it's
the
> right version etc.) Are there checks on the server side that the
> cross-package links are correct? Does the server make sure that the docs
> contain source links?
If I'm reading [1] correctly, no such checks are performed.
> If the answer to any of these questions is "no", I consider even the
> possibility of uploading docs by hand a bug. Wrong/partial documentation
is
> worse than no documentation at all...
You're welcome to open a ticket on the hackage-server bug tracker.
[1]
https://github.com/haskell/hackage-server/blob/master/Distribution/Server/Features/Documentation.hs#L223
------------------------------
Message: 16
Date: Wed, 20 Jan 2016 08:51:23 +0100
From: Joachim Durchholz <jo at durchholz.org>
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] CPU with Haskell support
Message-ID: <569F3C7B.80508 at durchholz.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Am 19.01.2016 um 23:12 schrieb Henning Thielemann:
>
> Fortunately, there are
> processors that are designed for custom instruction set extensions:
> https://en.wikipedia.org/wiki/Xtensa
Unfortunately, the WP article does not say anything that couldn't be
said about, say, an ARM core. Other than that Xtensa core being some
VLIW design.
> Would it be sensible to create a processor based on such a design?
Very, very unlikely, for multiple reasons.
Special-purpose CPUs have been built, most notably for LISP, less
notably for Java, and probably for other purposes that I haven't heard of.
Invariably, their architectural advantages were obsoleted by economy of
scale: Mainstream CPUs are being produced in such huge numbers that
Intel etc. could affort more engineers to optimize every nook and
cranny, more engineers to optimize the structure downscaling, and larger
fabs that could do more chips on more one-time expensive but per-piece
cheap equipment, and in the end, the special-purpose chips were slower
and more expensive. It's an extremely strong competition you are facing
if you try this.
Also, it is very easy to misidentify the actual bottlenecks and make
instructions for the wrong ones.
If caching is the main bottleneck (which it usually is), no amount of
CPU improvement will help you and you'll simply need a larger cache. Or,
probably, a compiler that knows enough about the program and its data
flow to arrange the data in a cache-line-friendly fashion.
I do not think this is going to be a long-term problem though. Pure
languages have huge advantages for fine-grained parallel processing, and
CPU technology is pushing towards multiple cores, so that's a natural
match. As pure languages come into more widespread use, the engineers at
Intel, AMD etc. will look at what the pure languages need, and add
optimizations for these.
Just my 2 cents.
Jo
------------------------------
Message: 17
Date: Wed, 20 Jan 2016 09:49:31 +0100
From: Sven Panne <svenpanne at gmail.com>
To: Mikhail Glushenkov <mikhail.glushenkov at gmail.com>
Cc: "cabal-devel at haskell.org" <cabal-devel at haskell.org>,
"haskell-cafe at haskell.org" <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] Doc generation?
Message-ID:
<CANBN=muhAXJaQQcTsbYGdsva-cTgC8si+U+-_Mjzt8Z3iJLZMA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
2016-01-20 8:35 GMT+01:00 Mikhail Glushenkov <mikhail.glushenkov at gmail.com>:
> You're welcome to open a ticket on the hackage-server bug tracker.
>
I've reported this several times through several channels, not sure if yet
another report will have an impact. Here a quick summary of
doc-generation-related issues:
https://github.com/haskell/hackage-server/issues/464
https://github.com/haskell/hackage-server/issues/463
https://github.com/haskell/hackage-server/issues/421
https://github.com/haskell/hackage-server/issues/420
https://github.com/haskell/hackage-server/issues/368
https://github.com/haskell/hackage-server/issues/244
https://github.com/haskell/hackage-server/issues/183
https://github.com/haskell/hackage-server/issues/145
https://github.com/haskell/hackage-server/issues/55
>From a packager maintainer POV, it's totally unpredictable if/when
documentation gets built, see e.g.
http://hackage.haskell.org/package/GLURaw-2.0.0.1: Currently there are no
docs, while the previous version had docs, and the only change was relaxing
the upper bound of OpenGLRaw (
https://github.com/haskell-opengl/GLURaw/compare/v2.0.0.0...v2.0.0.1).
Basically I gave up any hope and rely on stackage and/or local docs... :-(
Cheers,
S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/505370f1/attachment.html
>
------------------------------
Subject: Digest Footer
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
------------------------------
End of Haskell-Cafe Digest, Vol 149, Issue 18
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/572a420d/attachment-0001.html>
More information about the Haskell-Cafe
mailing list