Bakul Shah wrote a particularly elegant Scheme program for Chudnovskys'
algorithm for pi based on the Common Lisp program here:
https://bitbucket.org/tarballs_are_good/numericl/src/5fe8fe7089f48ab1c8a388…
Nick Craig-Wood wrote a Python program using the GMP multiprecision
library that appears to use exactly the same algorithm here:
http://www.craig-wood.com/nick/articles/pi-chudnovsky/
I modified both programs a bit and include them here.
They time the calculation of $10^n$ digits of pi …
[View More]for $n=1,2,3,4,5,6,7$.
The results are
heine:~/programs/gambiteer/gambit> !py
python pi_chudnovsky_bs_gmpy.py
31415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679
('chudnovsky_gmpy_mpz_bs: digits', 10, 'time', 1.0967254638671875e-05)
('chudnovsky_gmpy_mpz_bs: digits', 100, 'time', 3.0040740966796875e-05)
Last 5 digits 70679 OK
('chudnovsky_gmpy_mpz_bs: digits', 1000, 'time', 0.00025582313537597656)
Last 5 digits 01989 OK
('chudnovsky_gmpy_mpz_bs: digits', 10000, 'time', 0.00386810302734375)
Last 5 digits 75678 OK
('chudnovsky_gmpy_mpz_bs: digits', 100000, 'time', 0.0834801197052002)
Last 5 digits 24646 OK
('chudnovsky_gmpy_mpz_bs: digits', 1000000, 'time', 1.655979871749878)
Last 5 digits 58151 OK
('chudnovsky_gmpy_mpz_bs: digits', 10000000, 'time', 30.67442488670349)
Last 5 digits 55897 OK
heine:~/programs/gambiteer/gambit> gsi chud1.scm
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
10, CPU time: 0..
Last 5 digits 26535.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
100, CPU time: 0..
Last 5 digits 70679.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
1000, CPU time: .004.
Last 5 digits 1989.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
10000, CPU time: .028.
Last 5 digits 75678.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
100000, CPU time: .472.
Last 5 digits 24646.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
1000000, CPU time: 6.448.
Last 5 digits 58151.
Chudnovsky's algorithm using binary splitting in Gambit Scheme: digits
10000000, CPU time: 98.612.
Last 5 digits 55897.
So it appears that for this algorithm applied to large integers, GMP's
bignum routines are about 3-4 times as fast as Gambit's bignum
routines. Not so bad. For smaller bignums, GMP has a bigger advantage.
The C program gmp-chudnovsky.c includes certain optimizations to this
basic algorithm:
http://gmplib.org/pi-with-gmp.htmlftp://ftp.gmplib.org/pub/misc/gmp-chudnovsky.c
On my machine, compiled with
gcc -O3 -march=native -o gmp-chudnovsky gmp-chudnovsky.c -lgmp -lm
the CPU times for 1,000,000 and 10,000,000 digits are 1.064 and 18.200
seconds, respectively.
This is with a somewhat older machine
model name : Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz
running Ubuntu 13.04 with
heine:~/programs/gambiteer/gambit> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --with-system-zlib
--enable-objc-gc --with-cloog --enable-cloog-backend=ppl
--disable-cloog-version-check --disable-ppl-version-check
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
heine:~/programs/gambiteer/gambit> gsi -v
v4.6.9 20130607151908 x86_64-unknown-linux-gnu "./configure
'--enable-single-host' '--enable-multiple-versions' '--enable-shared'"
and the Ubuntu-provided GMP 5.0.5. (I'm sure the GMP folks have a
better way to build GMP on my machine than the "generic" 64-bit version
provided by Ubuntu.)
Brad
[View Less]
First of all, this change is for the universal backend. It is more of a temporary kludge to experiment with dynamically loading files generated by the universal backend. Here’s how it works…
At the end of the link file, the Gambit linker generates a table of the Scheme modules required by the program. The table is passed as a parameter to the g_module_registry_init function of the Gambit runtime system. For example, the link command:
gsc -link -l lib/_gambit.js a.js b.js
will generate …
[View More]at the end of the link file “b_.js”:
g_module_registry_init([new G_ModLinkInfo("_gambit",0),
new G_ModLinkInfo("a",1),
new G_ModLinkInfo("b",2)]);
At then end of a file generated for the compilation of a module there is a call to a runtime system function that registers the module in the module registry. For example, when “a.scm” is compiled with the command “gsc -target js -c a.scm”, the file “a.js” generated ends with:
g_module_register([g_make_interned_symbol("a"),g_bb1__20_a,1,null,false]);
The parameter of g_module_register is a “module descriptor” giving information on the module: name, main function (g_bb1__20_a), preload flag (1), module meta information (null), and a dummy field (false) that is only interesting for the C backend.
So when the files of generated code are loaded (incrementally) by the JS VM, g_module_register accumulates the modules in a table. When all the modules required by the program have beed loaded (in the example, _gambit, a and b) the function g_module_register will call the main function of the first module. This will run the Scheme code at the toplevel of the first module.
The first module contains a loop, in Scheme, that iterates over the module registry and calls the main function of each of the remaining modules in the registry (this information is available in Scheme in the global variable ##program-descr). Specifically, the first module is the Gambit universal library (lib/_univlib.scm), which ends with a call to ##load-vm (a procedure defined in lib/_kernel.scm that runs each module other than the first).
What my most recent change does is extend g_module_register so that any subsequent module that is loaded by the JS VM causes its immediate execution by calling the module's main function. In the C backend the mechanism is slightly different (and more flexible): the ##load-object-file procedure of the Gambit runtime library constructs a vector of module descriptors and this vector is passed to ##register-module-descrs-and-load! (defined in lib/_kernel.scm) which then runs the modules. It is more flexible because the loaded object file can contain more than one module, and also control goes through Scheme before the module is executed.
Marc
> On Jan 3, 2016, at 2:54 AM, Adam <adam.mlmb(a)gmail.com> wrote:
>
> Marc,
>
> Wait, what's the point?
>
> That is effectively C modules' default behavior isn't it? (even if it's the runtime or linker-generated code that actually does the actual run command.)
>
> So this way you create symmetrical behavior but the actual run command is in the module file itself rather than in runtime/linker -
>
> Is there any disadvantage.. could be, no, like, I need more modules loaded at the same time and with this model you introduced now, the global namespace in JS files is evaluated at load time so could cause a problem?
>
>
> 2016-01-03 14:10 GMT+08:00 Marc Feeley <feeley(a)iro.umontreal.ca>:
> I’ve just pushed a small change to the module registration method. Now, loading the generated .js file will run that file.
>
> Marc
>
> > On Jan 2, 2016, at 11:39 PM, Blake McBride <blake(a)mcbride.name> wrote:
> >
> > Yes, and I use jQuery get and html methods to load the html part.
> >
> >
> > On Sat, Jan 2, 2016 at 8:43 PM, Marc Feeley <feeley(a)iro.umontreal.ca> wrote:
> > That’s an interesting app!
> >
> > As I said, it shouldn’t be hard to do. In your app, how do you load new JS code? Are you using jQuery and the getScript method?
> >
> > Marc
> >
> > > On Jan 2, 2016, at 8:42 PM, Blake McBride <blake(a)mcbride.name> wrote:
> > >
> > > Hi Marc,
> > >
> > > Thanks for the reply.
> > >
> > > I started development of a Web based business application in 2006. The app is in production use. The front-end is about 450 screens written in Flash. The back-end is written in Java (over 9,000 classes) on top of an SQL database with 250 tables accessed through Hibernate. The front-end and back-end communicate through SOAP web services.
> > >
> > > Since Flash is now dead, I need to re-write at least parts of the front-end in JS to support tablets and phones at least. I have front-end JS code that communicates with the back-end SOAP Web services so I theoretically wouldn't need to touch the back-end.
> > >
> > > I have a preference to utilize scheme if I can, but the back-end is already written and works. It doesn't make sense to mess with it given the investment.
> > >
> > > The problems I had with Gambit (as well as many other systems) is as follows:
> > >
> > > Once a user logs in, my app has a consistent visual / UI framework. Beyond this framework, there are 450 different screens that appear within the framework (like in one of the div's).
> > >
> > > A. I cannot load all 450 screen at system startup. I must lazy load them as they are called up.
> > >
> > > B. The initial UI framework code should contain all of the Gambit machinery and libraries so that each of the 450 screens can be small, light-weight, compiled separately yet have full access to the entire Gambit facility.
> > >
> > > With respect, my investigation into Gambit as a possible solution in the past led me to the conclusions at that time it was not possible to produce separately compiled modules that leveraged off of a single main module for the Gambit machinery and libraries.
> > >
> > > I suppose some time has passed and I wanted to see if the situation has changed. I can only use Gambit if:
> > >
> > > 1. I can compile and load each screen separately
> > >
> > > 2. I only have to have one copy of the Gambit machinery and library so that the separate screens are small.
> > >
> > > Thank you.
> > >
> > > Blake
> > >
> > >
> > > On Sat, Jan 2, 2016 at 7:06 PM, Marc Feeley <feeley(a)iro.umontreal.ca> wrote:
> > > asmjs is cool and Gambit has already been compiled to it thanks to emscripten (see “Gambit in the browser”: http://feeley.github.io/gambit-in-the-browser/). The performance is not bad, perhaps 10x to 20x slower than when Gambit is compiled by gcc to native code. The main problem is the size of the JS that is generated when compiling Gambit-C with emscripten to JS. The gsi interpreter yields roughly 10 MB of asmjs code.
> > >
> > > As far as code size is concerned, a better solution is to use Gambit's JS backend with the Gambit library. The code generated is roughly half the size when minimized (and it could be even less if some thought went into how identifiers are encoded).
> > >
> > > Even more savings can be had by doing away with the default Gambit library and writing a custom library specialized for the application. Gambit’s library has lots of functionality that is not normally needed by typical applications. For example, the predefined map procedure can handle an arbitrary number of list parameters. If the application only uses the single list version, then this definition would be sufficient:
> > >
> > > (define (map f lst)
> > > (if (pair? lst)
> > > (cons (f (car lst)) (map f (cdr lst)))
> > > ‘()))
> > >
> > > That 4 line version is 1/20th the size of the map defined in the Gambit library (which handles multiple lists, has type checking, precise error messages, same list length checking and is safe for multithreading).
> > >
> > > So perhaps what’s needed for Gambit to be more successful for web dev is the creation of such a “slim” library for Gambit to replace the default feature-full library. Gambit’s “tree shaker” would also help to eliminate the unused procedures of the slim library (unfortunately this only works for “whole program” compilation, so separate compilation would only be used for the development phase).
> > >
> > > Anyway, if this interests you please let me know.
> > >
> > > Marc
> > >
> > > > On Jan 1, 2016, at 11:44 AM, Blake McBride <blake(a)mcbride.name> wrote:
> > > >
> > > > Just some opinions.
> > > >
> > > > asmjs.org defines a portable subset that allows JS platforms to compile into very fast code. Targeting that subset, and within their spec, is probably a good idea.
> > > >
> > > > JS has, and is becoming increasingly, a very, very important platform. With ajax and rest services, code increasingly independent from the back-end is being developed. So, in a very important sense, JS has become its own platform, just like X86, and X86_64, along with Linux, Windows, Mac, etc.
> > > >
> > > > Many apps consist of two major parts: the back-end processing, and the front-end human interface. While one can write the back-end processing in any of dozens of languages targeting X86 or a VM, and the OS, there is really only one target for the other half - the human interface - and that is JS.
> > > >
> > > > While many languages are now targeting the JS platform (I am using the word "platform" to mean X86, X86_64, either, plus the OS) including, believe it or not, Smalltalk, there are few that can, IMO, be used in a real world application for several reasons. But, these issues will likely be resolved soon.
> > > >
> > > > With respect, Gambit, at least in the past, was in many ways another toy solution - one with a functioning "Hello world" application but missing important features that make it usable in a real-world situation. I would love to be a part of that solution, but alas, life doesn't offer me that level of freedom. I am only capable of using a system that is reportedly working, reporting bugs, making small adjustments, and providing feedback. Regardless of my attitude, preferences, and intentions, I cannot provide more.
> > > >
> > > > Look at node (JS for the back-end) and its vastly increasing popularity. Since developers are being forced to use JS on the front-end, it's bleeding over to the back-end. I think solutions that take JS seriously at this stage will prosper greatly.
> > > >
> > > > Now, having said all that, I would love to see Gambit target JS as a high-priority, first-class target. If that were the case, I would be happy to contribute what I stated above.
> > > >
> > > > Thanks!
> > > >
> > > > Blake McBride
> > > >
> > > > _______________________________________________
> > > > Gambit-list mailing list
> > > > Gambit-list(a)iro.umontreal.ca
> > > > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
> > >
> > >
> >
> >
>
> _______________________________________________
> Gambit-list mailing list
> Gambit-list(a)iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>
[View Less]
Thank you!
I was missing an option: -Wl,--no-as-needed
Francois Magnan
> On Apr 28, 2016, at 12:11 PM, Marc Feeley <dr.marc.feeley(a)gmail.com> wrote:
>
> As a general rule it is best to let gsc do the linking of the executable program (using the -exe option) so that any necessary linker options are passed to the C compiler. You can check which linking options are necessary by passing the -verbose option to gsc when compiling a small dummy program.
>
> My guess is that …
[View More]the order of the -ldl and -lutil options is important. Can you try putting them at the end of the options passed to gcc?
>
> Marc
>
>> On Apr 28, 2016, at 11:06 AM, Francois Magnan <fmagnan(a)me.com> wrote:
>>
>> Hi,
>>
>> I am trying to compile my program on the latest Ubuntu release
>>
>> gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2)
>>
>> I have the lastest gambit that compiled flawlessly:
>>
>> /usr/local/Gambit/bin/gsc -v
>> v4.8.5 20160401231324 x86_64-unknown-linux-gnu “./configure '--enable-single-host' '--enable-gcc-opts'"
>>
>> I build my program using:
>>
>> /usr/local/Gambit/bin/gsc -:f8,t8,-8 -link loader
>> gcc -o athena loader.c loader_.c -lutil -ldl -lm -L/usr/local/Gambit/lib/ /usr/local/Gambit/lib/libgambit.a -I/usr/local/Gambit/include/
>>
>>
>> but at link I get the following error:
>>
>> /usr/local/Gambit/lib/libgambit.a(os_dyn.o): In function `___dynamic_load':
>> os_dyn.c:(.text+0x1c0): undefined reference to `dlopen'
>> os_dyn.c:(.text+0x1d4): undefined reference to `dlsym'
>> os_dyn.c:(.text+0x1ec): undefined reference to `dlerror'
>> os_dyn.c:(.text+0x228): undefined reference to `dlclose'
>> /usr/local/Gambit/lib/libgambit.a(os_dyn.o): In function `___cleanup_dyn_module':
>> os_dyn.c:(.text+0x3dc): undefined reference to `dlclose'
>> /usr/local/Gambit/lib/libgambit.a(os_io.o): In function `___device_stream_setup_from_process':
>> os_io.c:(.text+0x21cc): undefined reference to `openpty'
>> collect2: error: ld returned 1 exit status
>>
>>
>> Any hint on what is wrong?
>>
>> Thank you,
>> Francois Magnan
>>
>>
>>
>>
>> _______________________________________________
>> Gambit-list mailing list
>> Gambit-list(a)iro.umontreal.ca
>> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>
[View Less]
Hi,
I am trying to compile my program on the latest Ubuntu release
gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2)
I have the lastest gambit that compiled flawlessly:
/usr/local/Gambit/bin/gsc -v
v4.8.5 20160401231324 x86_64-unknown-linux-gnu “./configure '--enable-single-host' '--enable-gcc-opts'"
I build my program using:
/usr/local/Gambit/bin/gsc -:f8,t8,-8 -link loader
gcc -o athena loader.c loader_.c -lutil -ldl -lm -L/usr/local/Gambit/lib/ /usr/local/Gambit/lib/libgambit.a -…
[View More]I/usr/local/Gambit/include/
but at link I get the following error:
/usr/local/Gambit/lib/libgambit.a(os_dyn.o): In function `___dynamic_load':
os_dyn.c:(.text+0x1c0): undefined reference to `dlopen'
os_dyn.c:(.text+0x1d4): undefined reference to `dlsym'
os_dyn.c:(.text+0x1ec): undefined reference to `dlerror'
os_dyn.c:(.text+0x228): undefined reference to `dlclose'
/usr/local/Gambit/lib/libgambit.a(os_dyn.o): In function `___cleanup_dyn_module':
os_dyn.c:(.text+0x3dc): undefined reference to `dlclose'
/usr/local/Gambit/lib/libgambit.a(os_io.o): In function `___device_stream_setup_from_process':
os_io.c:(.text+0x21cc): undefined reference to `openpty'
collect2: error: ld returned 1 exit status
Any hint on what is wrong?
Thank you,
Francois Magnan
[View Less]
**Call for Papers**
========================================================================
9th ACM SIGPLAN International Conference on Software Language Engineering
(SLE 2016)
Oct 31-Nov 1, 2016, Amsterdam, Netherlands
(Co-located with SPLASH 2016)
General chair:
Tijs van der Storm, CWI, Netherlands
Program co-chairs:
Dániel Varro, Budapest University of Technology and Economics, Hungary
Emilie Balland, Sensational AG, Switzerland
http://conf.researchr.org/track/sle-2016/…
[View More]sle-2016-papershttp://www.sleconf.org/2016/
Follow us on twitter: https://twitter.com/sleconf
========================================================================
Software Language Engineering (SLE) is the application of systematic,
disciplined, and measurable approaches to the development, use, deployment,
and maintenance of software languages. The term "software language" is used
broadly, and includes: general-purpose programming languages;
domain-specific languages (e.g. BPMN, Simulink, Modelica); modeling and
metamodeling languages (e.g. SysML and UML); data models and ontologies
(e.g. XML-based and OWL-based languages and vocabularies).
### Important Dates
Fri 17 Jun 2016 - Abstract Submission
Fri 24 Jun 2016 - Paper Submission
Fri 26 Aug 2016 - Notification
Fri 2 Sep 2016 - Artifact submission
Fri 16 Sep 2016 - Artifact notification
Fri 16 Sep 2016 - Camera ready deadline
Mon 31 Oct 09:00 - Tue 1 Nov 18:00 2016 Conference
### Topics of Interest
SLE aims to be broad-minded and inclusive about relevance and scope. We
solicit high-quality contributions in areas ranging from theoretical and
conceptual contributions to tools, techniques, and frameworks in the domain
of language engineering. Topics relevant to SLE cover generic aspects of
software languages development rather than aspects of engineering a
specific language. In particular, SLE is interested in principled
engineering approaches and techniques in the following areas:
* Language Design and Implementation
* Approaches and methodologies for language design
* Static semantics (e.g., design rules, well-formedness constraints)
* Techniques for behavioral / executable semantics
* Generative approaches (incl. code synthesis, compilation)
* Meta-languages, meta-tools, language workbenches
* Language Validation
* Verification and formal methods for languages
* Testing techniques for languages
* Simulation techniques for languages
* Language Integration
* Coordination between of heterogeneous languages and tools
* Mappings between languages (incl. transformation languages)
* Traceability between languages
* Deployment of languages to different platforms
* Language Maintenance
* Software language reuse
* Language evolution
* Language families and variability
* Domain-specific approaches for any aspects of SLE (design,
implementation, validation, maintenance)
* Empirical evaluation and experience reports of language engineering tools
* User studies evaluating usability
* Performance benchmarks
* Industrial applications
### Types of Submissions
* **Research papers**: These should report a substantial research
contribution to SLE or successful application of SLE techniques or both.
Full paper submissions must not exceed 12 pages excluding bibliography (in
ACM SIGPLAN conference style (http://www.sigplan.org/Resources/Author/)).
* **Tool papers**: Because of SLE’s interest in tools, we seek papers that
present software tools related to the field of SLE. Selection criteria
include originality of the tool, its innovative aspects, and relevance to
SLE. Any of the SLE topics of interest are appropriate areas for tool
demonstrations. Submissions must provide a tool description of 4 pages in
SIGPLAN proceedings style (see above), with 1 optional additional page for
bibliographic references, and a demonstration outline including screenshots
of up to 4 pages. Tool demonstrations must have the keywords "Tool Demo" or
“Tool Demonstration” in the title. The 4-page tool description will, if the
demonstration is accepted, be published in the proceedings. The 4-page
demonstration outline will be used by the program committee only for
evaluating the submission.
### Artifact evaluation
Authors of accepted papers at SLE 2016 are encouraged to submit their
experiment results used for underpinning research statements to an artifact
evaluation process carried out in early September 2016. This submission is
voluntary and will not influence the final decision regarding the papers.
Papers that go through the Artifact Evaluation process successfully receive
a seal of approval printed on the first page of the paper in the
proceedings. Authors of papers with accepted artifacts are encouraged to
make these materials publicly available upon publication of the
proceedings, by including them as "source materials" in the ACM Digital
Library.
### Publications
All submitted papers will be reviewed by at least three members of the
program committee. All accepted papers, including tool papers will be
published in ACM Digital Library.
Authors of distinguished papers from the conference will be invited to
revise and submit extended versions of their papers for a Journal special
issue.
### Awards
* Distinguished paper. Award for most notable paper, as determined by the
PC chairs based on the recommendations of the program committee.
* Distinguished reviewer. Award for distinguished reviewer, as determined
by the PC chairs using feedback from the authors.
### Program Committee
Emilie Balland (co-chair), Sensational AG (SUI)
Daniel Varro (co-chair), BME (HUN)
Anya Helene Bagge, Univ. Bergen (NOR)
Ruth Breu, Univ. Innsbruck (AUT)
Jordi Cabot, Univ. Oberta de Catalunya (ESP)
Marsha Chechik, Univ. Toronto (CAN)
Marcus Denker, INRIA (FRA)
Davide Di Ruscio, Univ. L’Aquila (ITA)
Martin Erwig, Oregon State Univ. (USA)
Bernd Fischer, Stellenbosch University (RSA)
Sebastian Gerard, CEA (FRA)
Jeremy Gibbons, Oxford Univ. (UK)
Holger Giese, Hasso Plattner Inst. (GER)
Martin Gogolla, Univ. Bremen (GER)
Jeff Gray, Univ. Alabama (USA)
Esther Guerra, Autonomous Univ. of Madrid (ESP)
Gorel Hedin, Lund Univ. (SWE)
Michael Homer, Victoria Univ. Wellington (NZL)
Dimitris Kolovos, Univ. York (UK)
Ralf Lämmel, Univ. Koblenz (GER)
Julia Lawall, LIP6 (FRA)
Tihamer Levendovszky, Microsoft (USA)
Heather Miller, EPFL (SUI)
Pierre-Etienne Moreau, Loria (FRA)
Günter Mussbacher, McGill Univ. (CAN)
Bruno Oliveira, Univ. of Hong Kong (HKG)
Terence Parr, Univ. San Francisco (USA)
István Ráth, IncQuery Labs (HUN)
Julia Rubin, MIT (USA)
Bernhard Schatz, Fortiss (GER)
Sibylle Schupp, Univ. Hamburg (GER)
Anthony Sloane, Macquarie Univ. (AUS)
Emma Söderberg, Google (USA)
Eugene Syriani, Univ. Montréal (CAN)
Gabi Taentzer, Univ. Marburg (GER)
Eric Van Wyk, Univ. Minnesota (USA)
Hans Vangheluwe, Univ. Antwerp (BEL)
Jurgen Vinju, CWI (NED)
Guido Wachsmuth, TU Delft (NED)
Eric Walkingshaw, Oregon State Univ. (USA)
Andrzej Wąsowski, ITU (DEN)
Manuel Wimmer, TU Wien (AUT)
Tian Zhang, Nanjing Univ. (CHN)
[View Less]
TFP 2016 has extended its deadline for draft papers by two weeks (now
April 25). Although all draft papers accepted to TFP 2016 will be
invited to submit to the post-symposium formal proceedings, authors
are reminded that they are not obligated to do so; we welcome works in
progress that may not be destined for the TFP proceedings.
Thanks,
David Van Horn
-----------------------------
C A L L F O R P A P E R S
-----------------…
[View More]------------
======== TFP 2016 ===========
17th Symposium on Trends in Functional Programming
June 8-10, 2016
University of Maryland, College Park
Near Washington, DC
http://tfp2016.org/
The symposium on Trends in Functional Programming (TFP) is an
international forum for researchers with interests in all aspects of
functional programming, taking a broad view of current and future
trends in the area. It aspires to be a lively environment for
presenting the latest research results, and other contributions (see
below). Authors of draft papers will be invited to submit revised
papers based on the feedback receive at the symposium. A
post-symposium refereeing process will then select a subset of these
articles for formal publication.
TFP 2016 will be the main event of a pair of functional programming
events. TFP 2016 will be accompanied by the International Workshop on
Trends in Functional Programming in Education (TFPIE), which will take
place on June 7nd.
== INVITED SPEAKERS ==
TFP 2016 is pleased to announce keynote talks by the following two
invited speakers:
* Ronald Garcia, University of British Columbia: "Static and Dynamic
Type Checking: A Synopsis"
* Steve Zdancewic, University of Pennsylvania: "Type- and
Example-Driven Program Synthesis"
== HISTORY ==
The TFP symposium is the heir of the successful series of Scottish
Functional Programming Workshops. Previous TFP symposia were held in
* Edinburgh (Scotland) in 2003;
* Munich (Germany) in 2004;
* Tallinn (Estonia) in 2005;
* Nottingham (UK) in 2006;
* New York (USA) in 2007;
* Nijmegen (The Netherlands) in 2008;
* Komarno (Slovakia) in 2009;
* Oklahoma (USA) in 2010;
* Madrid (Spain) in 2011;
* St. Andrews (UK) in 2012;
* Provo (Utah, USA) in 2013;
* Soesterberg (The Netherlands) in 2014;
* and Inria Sophia-Antipolis (France) in 2015.
For further general information about TFP please see the TFP homepage.
(http://www.tifp.org/).
== SCOPE ==
The symposium recognizes that new trends may arise through various
routes. As part of the Symposium's focus on trends we therefore
identify the following five article categories. High-quality articles
are solicited in any of these categories:
Research Articles: leading-edge, previously unpublished research work
Position Articles: on what new trends should or should not be
Project Articles: descriptions of recently started new projects
Evaluation Articles: what lessons can be drawn from a finished project
Overview Articles: summarizing work with respect to a trendy subject
Articles must be original and not simultaneously submitted for
publication to any other forum. They may consider any aspect of
functional programming: theoretical, implementation-oriented, or
experience-oriented. Applications of functional programming
techniques to other languages are also within the scope of the
symposium.
Topics suitable for the symposium include, but are not limited to:
Functional programming and multicore/manycore computing
Functional programming in the cloud
High performance functional computing
Extra-functional (behavioural) properties of functional programs
Dependently typed functional programming
Validation and verification of functional programs
Debugging and profiling for functional languages
Functional programming in different application areas:
security, mobility, telecommunications applications, embedded
systems, global computing, grids, etc.
Interoperability with imperative programming languages
Novel memory management techniques
Program analysis and transformation techniques
Empirical performance studies
Abstract/virtual machines and compilers for functional languages
(Embedded) domain specific languages
New implementation strategies
Any new emerging trend in the functional programming area
If you are in doubt on whether your article is within the scope of
TFP, please contact the TFP 2016 program chair, David Van Horn.
== BEST PAPER AWARDS ==
To reward excellent contributions, TFP awards a prize for the best paper
accepted for the formal proceedings.
TFP traditionally pays special attention to research students,
acknowledging that students are almost by definition part of new
subject trends. A student paper is one for which the authors state
that the paper is mainly the work of students, the students are listed
as first authors, and a student would present the paper. A prize for
the best student paper is awarded each year.
In both cases, it is the PC of TFP that awards the prize. In case the
best paper happens to be a student paper, that paper will then receive
both prizes.
== SPONSORS ==
TFP is financially supported by CyberPoint, Galois, Trail of Bits, and
the University of Maryland Computer Science Department.
== PAPER SUBMISSIONS ==
Acceptance of articles for presentation at the symposium is based on a
lightweight peer review process of extended abstracts (4 to 10 pages
in length) or full papers (20 pages). The submission must clearly
indicate which category it belongs to: research, position, project,
evaluation, or overview paper. It should also indicate which authors
are research students, and whether the main author(s) are students. A
draft paper for which ALL authors are students will receive additional
feedback by one of the PC members shortly after the symposium has
taken place.
We use EasyChair for the refereeing process. Papers must be submitted at:
https://easychair.org/conferences/?conf=tfp2016
Papers must be written in English, and written using the LNCS
style. For more information about formatting please consult the
Springer LNCS web site:
http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0
== IMPORTANT DATES ==
Submission of draft papers: April 25, 2016
Notification: May 2, 2016
Registration: May 13, 2016
TFP Symposium: June 8-10, 2016
Student papers feedback: June 14, 2016
Submission for formal review: July 14, 2016
Notification of acceptance: September 14, 2016
Camera ready paper: October 14, 2016
== PROGRAM COMMITTEE ==
Amal Ahmed Northeastern University (US)
Nada Amin École Polytechnique Fédérale de Lausanne (CH)
Kenichi Asai Ochanomizu University (JP)
Małgorzata Biernacka University of Wroclaw (PL)
Laura Castro University of A Coruña (ES)
Ravi Chugh University of Chicago (US)
Silvia Ghilezan University of Novi Sad (SR)
Clemens Grelck University of Amsterdam (NL)
John Hughes Chalmers University of Technology (SE)
Suresh Jagannathan Purdue University (US)
Pieter Koopman Radboud University Nijmegen (NL)
Geoffrey Mainland Drexel University (US)
Chris Martens University of California, Santa Cruz (US)
Jay McCarthy University of Massachusetts, Lowell (US)
Heather Miller École Polytechnique Fédérale de Lausanne (CH)
Manuel Serrano INRIA, Sophia-Antipolis (FR)
Scott Smith Johns Hopkins University (US)
Éric Tanter University of Chile (CL)
David Van Horn (Chair) University of Maryland (US)
Niki Vazou University of California, San Diego (US)
Stephanie Weirich University of Pennsylvania (US)
[View Less]
Nothing to do with Gambit, but I thought I’d compare a Raspberry Pi 2 B (RPi2B) with a RPi3B using the linpack double-precision benchmark.
On Rpi2B compiled with
gcc -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -Ofast -o linpackc_new linpackc_new.c
I get
cutie-pi:~> ./linpackc_new
Enter array size (q to quit) [200]: 200
Memory required: 315K.
LINPACK benchmark, Double precision.
Machine precision: 15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
…
[View More]Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.67 88.31% 2.85% 8.84% 143587.934
128 1.34 88.31% 2.85% 8.84% 143539.628
256 2.69 88.26% 2.88% 8.86% 143610.046
512 5.35 88.28% 2.86% 8.86% 144172.103
1024 10.70 88.28% 2.86% 8.85% 144153.024
Enter array size (q to quit) [200]: 1000
Memory required: 7824K.
LINPACK benchmark, Double precision.
Machine precision: 15 digits.
Array size 1000 X 1000.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
1 1.62 96.95% 0.59% 2.46% 106370.268
2 3.17 97.78% 0.60% 1.62% 107598.577
4 6.37 97.78% 0.60% 1.61% 107021.647
8 12.70 97.78% 0.60% 1.62% 107340.380
On RPi3 compiled with
gcc -Ofast -mcpu=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard -Ofast -o linpackc linpackc_new.c
I get
sweety-pi:~> ./linpackc
Enter array size (q to quit) [200]:
Memory required: 315K.
LINPACK benchmark, Double precision.
Machine precision: 15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
64 0.53 89.82% 2.83% 7.36% 178548.817
128 1.06 89.81% 2.83% 7.37% 178628.648
256 2.13 89.81% 2.82% 7.37% 178550.449
512 4.25 89.81% 2.82% 7.36% 178541.926
1024 8.50 89.81% 2.83% 7.37% 178647.415
2048 17.00 89.81% 2.83% 7.37% 178647.687
Enter array size (q to quit) [200]: 1000
Memory required: 7824K.
LINPACK benchmark, Double precision.
Machine precision: 15 digits.
Array size 1000 X 1000.
Average rolled and unrolled performance:
Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
1 1.02 97.47% 0.61% 1.92% 167558.926
2 2.08 97.42% 0.73% 1.84% 164153.213
4 4.06 97.87% 0.61% 1.52% 167576.385
8 8.13 97.87% 0.61% 1.52% 167558.026
16 16.26 97.87% 0.61% 1.52% 167568.545
Enter array size (q to quit) [200]: q
Both compilers are
sweety-pi:~> gcc --version
gcc (Raspbian 4.9.2-10) 4.9.2
This page:
https://www.raspberrypi.org/magpi/raspberry-pi-3-specs-benchmarks/
says of the Rpi3 "the Broadcom BCM2837 system-on-chip (SoC) includes four high-performance ARM Cortex-A53 processing cores running at 1.2GHz with 32kB Level 1 and 512kB Level 2 cache memory, a VideoCore IV graphics processor, and is linked to a 1GB LPDDR2 memory module on the rear of the board.” It also says the RAM runs at 900MHz.
It’s funny, but I can’t find a definitive answer about how much cache the RPi2B has, or what the memory speed is.
At any rate, the ratio of KFLOPS for the “small” (200 x 200) problem is 1.243 and the ratio of KFLOPS for the “large” (1000 x 1000) problem is 1.575.
So the RPi3B must have a much more efficient memory system than the RPi2B.
Brad
[View Less]
I’m having problems compiling Gambit with clang and --enable-single-host on OS X :
$ ./configure --enable-single-host CC=clang; make -j8
…
$ make check
------------ TEST 1 (debugging support)
../gsi/gsi -:~~bin=../bin,~~lib=../lib,~~include=../include -f debug.scm > test1.out
/bin/sh: line 1: 91157 Segmentation fault: 11 ../gsi/gsi -:~~bin=../bin,~~lib=../lib,~~include=../include -f debug.scm > test1.out
make[1]: *** [test1] Error 139
make: *** [check] Error 2
$ clang -v
Apple LLVM …
[View More]version 7.3.0 (clang-703.0.29)
Target: x86_64-apple-darwin15.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
With the same configure command but using GNU gcc, there is no problem.
I’m wondering if this is a code generation bug in clang introduced in the latest Xcode. Does someone have an older version of clang to check if this problem existed before?
Marc
[View Less]