Re: [racket-users] typed racket backend/ir & gpu computing
Thank you, Sam and Matthias. I'll have to come back to that project later, but this all looks useful. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] typed racket backend/ir & gpu computing
> On Dec 19, 2018, at 11:07 PM, wanderley.guimar...@gmail.com wrote: > > Can you give an example of a simple eDSL language? Not that I am not lazy but > I don’t have an idea of what to search. People consider stand-alone DSLs from embedded DSLs, and they also distinguish how programs written in eDSLs interact with their context. AWK is a stand-alone DSL. Many ad hoc configuration languages for sw systems are stand-alone DSLs. The format language of Racket is an embedded DSL. The only things that make sense of programs written in the format languages are its Racket interpreters (for example _format_ and _printf_) and the Racket string operations. Its interface is rigid; Racket values flow into the interpreter and, in the case of format, a string comes back. The language of Racket’s match is also an embedded DSL, and its interface to Racket is fluid. Racket programs can use match in arbitrary expression positions, match can all out to Racket (for example via ? clauses), and Racket can send values into match via ? and match expanders. The languages of syntax and syntax-parse are also embedded DSLs, and their interfaces are even more fluid than match’s. A syntax variable can be used in a syntax-parse match, created outside, flow into syntax templates, etc. The pattern language of syntax-parse interacts with the language of syntax variables and Racket and Racket’s template language. This example is a bit extreme but for those of you who know the languages, it is also quite clarifying. — Matthias -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] typed racket backend/ir & gpu computing
Can you give an example of a simple eDSL language? Not that I am not lazy but I don’t have an idea of what to search. On Wed, Dec 19, 2018 at 1:19 PM Matthias Felleisen wrote: > > embedded as opposed to stand-alone > > > On Dec 19, 2018, at 3:08 PM, Greg Hendershott > wrote: > > > > What is the "e" in "eDSL"? > > > > -- > > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to racket-users+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] typed racket backend/ir & gpu computing
embedded as opposed to stand-alone > On Dec 19, 2018, at 3:08 PM, Greg Hendershott > wrote: > > What is the "e" in "eDSL"? > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] typed racket backend/ir & gpu computing
What is the "e" in "eDSL"? -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] typed racket backend/ir & gpu computing
To clarify: neither my work nor Stephen's would allow you to re-use Typed Racket's typechecking or inference. Rather, we're working to make it easy to implement new eDSLs with custom type systems and intermediate representations while remaining macro-extensible. A few projects that have been inspiring to me on how to deal with some of the challenges of compiling high-level, functional languages for GPU computing are: - Harlan, Eric Holk's PhD project. It addresses high-level approaches to memory management and portability of first-class functions between CPU and GPU. (https://pqdtopen.proquest.com/doc/1810156180.html?FMT=ABS, https://github.com/eholk/harlan) - Accelerate, which embeds GPU programs written in a functional programming style in Haskell. (http://www.acceleratehs.org/) - BraidGL, which uses multi-stage programming and cross-phase persistent values to mediate the interaction between GPU and CPU code. (https://www.cs.cornell.edu/~asampson/media/papers/braid-oopsla2017-preprint.pdf) Having any of these ideas integrated with Racket's macros would be really exciting. I expect to have some of my tools stable enough to be usable by folks other than myself in the next month or so. If you're interested in building something and trying out an alpha, definitely send me an email. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] typed racket backend/ir & gpu computing
> On Dec 19, 2018, at 4:12 AM, Jesse Alama wrote: > > On 18 Dec 2018, at 0:39, Matthias Felleisen wrote: > >> Michael Ballantyne’s core language > > I somehow can't find this -- do you have a link? It’s in the works/ -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] typed racket backend/ir & gpu computing
On 18 Dec 2018, at 0:39, Matthias Felleisen wrote: > Michael Ballantyne’s core language I somehow can't find this -- do you have a link? -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] typed racket backend/ir & gpu computing
Neil, what you’re looking for are — Stephen Chang’s Turnstile — Michael Ballantyne’s core language projects. The first one is an alternative way to add types to an eDSL. You can get all the type information you need and you can perform all the static checking you want. The second one is aimed at providing a comprehensive framework for elaborating a complete eDSL (that also benefits from Racket’s extensibility) into a language that doesn’t have Racket’s semantics (and may even be shipped to a totally different backend). Both are research products, the second much more so than the first. Both can benefit from feedback by someone who’s willing to play and invest time. — Matthias > On Dec 17, 2018, at 2:17 PM, Sam Tobin-Hochstadt wrote: > > Typed Racket does not have an IR in the sense you describe, and the > Typed Racket internals are not exposed in a way that's intended for > general consumption. More generally, I think Typed Racket's type > system is not likely to be a good fit for GPU computation. > > If you want to give it a try, though, you should take a look at the > Typed Racket optimizer, and see if the type information there is what > you are looking for. You might start by looking at: > https://github.com/racket/typed-racket/blob/master/typed-racket-lib/typed-racket/optimizer/fixnum.rkt > which has optimizations on Fixnums. > > Sam > On Sun, Dec 16, 2018 at 1:40 AM Neil Van Dyke wrote: >> >> Is there a specified/stable Typed Racket intermediate representation >> that has all the type info resolved, and which separate projects could >> build upon, for other target backends or analysis? >> >> Reason for asking... >> >> I was idly thinking of various ways to do GPU/TPU "supercomputing" from >> a normal Racket program, or to specify GPU bits in a Racket-ish source >> language. >> >> One general way involves compiling a normal Racket/-ish program to both >> Racket VM and (at least some of the procedures or closures, or parts of >> same) to a language/IR like for OpenCL (or one of the other >> existing/emerging ones). From there, even a simple implementation might >> be able to do things like automatically run a chunk/extent of algorithm >> on the GPU, when a static/dynamic heuristic suggests that the overhead >> of going to GPU is worthwhile. >> >> Having very little time for this weekend side project, and not wanting >> to spend it reimplementing type inferencing or annotation... Is there a >> specified/stable IR of Typed Racket that would be easy to work with for >> this? (Or would it be easier to do something simple from scratch in >> Racket (like a syntax transformation-heavy `#lang`), or to try to adapt >> the Pre-Scheme C target for this purpose?) >> >> (I'm aware we could write numerical bits in, say, a C-like OpenCL >> language, and then do Racket FFI of the OpenCL API to run the GPU bits >> from our program otherwise coded in Racket. I'm more interested in the >> problem of ways of compiling a Racket-ish language to run on the GPU.) >> >> (Motivation: I have a new GPU computer toy, >> "https://www.neilvandyke.org/machine-learning/";, and, while some of my >> old Racket packages are still great for scraping/importing data for >> what's now called "data science", I then have to switch over to various >> growing stacks of software tools in other languages. Top-down, I could >> write wrappers to use some of those other tools from Racket. But I >> wonder whether there are opportunities being missed, from a potential >> Racket bottom-up, while most people are busy with the big ML/stats >> toolkits and the algorithmic languages that are currently popular in >> data science. Also, there is only so much Jupyter Notebook in a Web >> browser that a person can take, before they want to also understand more >> about the new metal. :) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to racket-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] typed racket backend/ir & gpu computing
Typed Racket does not have an IR in the sense you describe, and the Typed Racket internals are not exposed in a way that's intended for general consumption. More generally, I think Typed Racket's type system is not likely to be a good fit for GPU computation. If you want to give it a try, though, you should take a look at the Typed Racket optimizer, and see if the type information there is what you are looking for. You might start by looking at: https://github.com/racket/typed-racket/blob/master/typed-racket-lib/typed-racket/optimizer/fixnum.rkt which has optimizations on Fixnums. Sam On Sun, Dec 16, 2018 at 1:40 AM Neil Van Dyke wrote: > > Is there a specified/stable Typed Racket intermediate representation > that has all the type info resolved, and which separate projects could > build upon, for other target backends or analysis? > > Reason for asking... > > I was idly thinking of various ways to do GPU/TPU "supercomputing" from > a normal Racket program, or to specify GPU bits in a Racket-ish source > language. > > One general way involves compiling a normal Racket/-ish program to both > Racket VM and (at least some of the procedures or closures, or parts of > same) to a language/IR like for OpenCL (or one of the other > existing/emerging ones). From there, even a simple implementation might > be able to do things like automatically run a chunk/extent of algorithm > on the GPU, when a static/dynamic heuristic suggests that the overhead > of going to GPU is worthwhile. > > Having very little time for this weekend side project, and not wanting > to spend it reimplementing type inferencing or annotation... Is there a > specified/stable IR of Typed Racket that would be easy to work with for > this? (Or would it be easier to do something simple from scratch in > Racket (like a syntax transformation-heavy `#lang`), or to try to adapt > the Pre-Scheme C target for this purpose?) > > (I'm aware we could write numerical bits in, say, a C-like OpenCL > language, and then do Racket FFI of the OpenCL API to run the GPU bits > from our program otherwise coded in Racket. I'm more interested in the > problem of ways of compiling a Racket-ish language to run on the GPU.) > > (Motivation: I have a new GPU computer toy, > "https://www.neilvandyke.org/machine-learning/";, and, while some of my > old Racket packages are still great for scraping/importing data for > what's now called "data science", I then have to switch over to various > growing stacks of software tools in other languages. Top-down, I could > write wrappers to use some of those other tools from Racket. But I > wonder whether there are opportunities being missed, from a potential > Racket bottom-up, while most people are busy with the big ML/stats > toolkits and the algorithmic languages that are currently popular in > data science. Also, there is only so much Jupyter Notebook in a Web > browser that a person can take, before they want to also understand more > about the new metal. :) > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] typed racket backend/ir & gpu computing
Is there a specified/stable Typed Racket intermediate representation that has all the type info resolved, and which separate projects could build upon, for other target backends or analysis? Reason for asking... I was idly thinking of various ways to do GPU/TPU "supercomputing" from a normal Racket program, or to specify GPU bits in a Racket-ish source language. One general way involves compiling a normal Racket/-ish program to both Racket VM and (at least some of the procedures or closures, or parts of same) to a language/IR like for OpenCL (or one of the other existing/emerging ones). From there, even a simple implementation might be able to do things like automatically run a chunk/extent of algorithm on the GPU, when a static/dynamic heuristic suggests that the overhead of going to GPU is worthwhile. Having very little time for this weekend side project, and not wanting to spend it reimplementing type inferencing or annotation... Is there a specified/stable IR of Typed Racket that would be easy to work with for this? (Or would it be easier to do something simple from scratch in Racket (like a syntax transformation-heavy `#lang`), or to try to adapt the Pre-Scheme C target for this purpose?) (I'm aware we could write numerical bits in, say, a C-like OpenCL language, and then do Racket FFI of the OpenCL API to run the GPU bits from our program otherwise coded in Racket. I'm more interested in the problem of ways of compiling a Racket-ish language to run on the GPU.) (Motivation: I have a new GPU computer toy, "https://www.neilvandyke.org/machine-learning/";, and, while some of my old Racket packages are still great for scraping/importing data for what's now called "data science", I then have to switch over to various growing stacks of software tools in other languages. Top-down, I could write wrappers to use some of those other tools from Racket. But I wonder whether there are opportunities being missed, from a potential Racket bottom-up, while most people are busy with the big ML/stats toolkits and the algorithmic languages that are currently popular in data science. Also, there is only so much Jupyter Notebook in a Web browser that a person can take, before they want to also understand more about the new metal. :) -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
