Poly/ML

polyml@lists.polyml.org

695 discussions

Performance experiment with Poly/ML
by jesus-maria.aransay＠unirioja.es 25 Jul '13

25 Jul '13

Dear all, Jose Divas?n and I wrote a short paper for a Spanish workshop on functional programming ("Taller de Programaci?n Funcional 2013", http://babel.ls.fi.upm.es/tpf2013/) in which we test a SML program obtained with the Isabelle code generator tool to perform the Gauss Jordan elimination algorithm over matrices. We carried out performance experiments with MLton and Poly/ML with three different types of matrices. Matrices whose inputs were real numbers (SML type Real.real), matrices whose inputs were fractions of integers (IntInf.int) and also matrices whose inputs where an ad hoc implementation of the field Z2 by means of "0::IntInf.int" and "1::IntInf.int". The code generation process and the types mapping from Isabelle to SML are explained in pp. 1 - 4 of the article. The benchmarks comparing Poly/ML and MLton performance are detailed in pp. 4 - 8. Briefly, the results show that: - Poly/ML 5.5 performs better than MLton with matrices over Z2 (see page 6); - MLton behaves better than Poly/ML with matrices whose inputs are fractions of "IntInf.int" (see page 7); - Poly/ML 5.2 outperforms MLton over matrices of type "Real.real", but reaches a segmentation fault with matrices of size 800 * 800 (in computers with a RAM of 4GB). Quite surprisingly for us, Poly/ML 5.5 performs worse than Poly/ML 5.2 over matrices with inputs of type "Real.real". Our intention was just to identify the best performing setting (for compilation and execution) for our future work with matrices, and we did not get to explore the roots and reasons of the previous results. Anywhere, we considered that the results could be interesting for somebody in the mailing list. We would also be very pleased to get any feedback on the reasons for the previous results. The paper is available in the following link http://wiki.portal.chalmers.se/cse/uploads/ForMath/pavlap Thanks in advance for your interest, Jesus -- Jes?s Mar?a Aransay Azofra Universidad de La Rioja Dpto. de Matem?ticas y Computaci?n tlf.: (+34) 941299438 fax: (+34) 941299460 mail: jesus-maria.aransay at unirioja.es ; web: http://www.unirioja.es/cu/jearansa Edificio Luis Vives, c/ Luis de Ulloa s/n, 26004 Logro?o, Espa?a

3 2

Sourceforge and SVN
by David.Matthews＠prolingua.co.uk 24 Jun '13

24 Jun '13

I have "upgraded" the Poly/ML site on SourceForge (there didn't seem to be any choice) and as a consequence the subversion site has changed. Anyone who is following Poly/ML SVN will need to change to the new site. For trunk this is svn checkout svn://svn.code.sf.net/p/polyml/code/trunk polyml and for the 5.5 fixes branch svn co svn://svn.code.sf.net/p/polyml/code/fixes-5.5 polyml I am currently working on the stages of the compiler that process and optimise the intermediate code. These are parts of the compiler that haven't been looked at for a very long time and some of it was obviously translated automatically from my original Poly code back in the 1980s. I tend to commit changes fairly regularly rather than accumulate a long set of changes and commit all at once. This does mean that things could be broken and only fixed by a later commit but it makes it much easier to find a bug if it shows up much later. Season's greetings and best wishes for the New Year, David

3 5

ArraySlice.copy is inefficient
by peter.lammich＠uni-muenster.de 20 Jun '13

20 Jun '13

Hi all, (Referring to "PolyML 5.5.0 release") I am trying to copy the initial part of an array into another array, something like OCamls: "Array.blit src 0 dst 0 len" In PolyML, I have Array.copy, that copies the whole array, i.e., fixes len=length src, which is to restrictive for my purpose. I can solve my problem with "ArraySlice.copy {src=ArraySlice.slice(src,0,SOME len),di=0,dst=dst}" However, this solution has very poor performance. Looking at the code, it becomes clear why: Array.copy is implemented natively by "move_words", however, ArraySlice.copy is implemented as a recursive function inside ML. This is a performance difference of roughly two orders of magnitude! There is a comment on ArraySlice.copy that "We can't use System_move_words because of the potential overlap problem." However, looking at the implementations of move_words, I find: x86asm.asm: ;# Must deal with the case of overlapping segments correctly. (which the implementation there does) run_time.cpp: memmove(dest, source, words*sizeof(PolyWord)); /* must work for overlapping segments. */ (which it does according to C++ specification) Nevertheless, a quick test reveals that System_move_words does not work for overlapping memory! What am I missing? So, this results in a few questions: 1) Is there a fast solution two my problem within the SML-standard, where I can even assume that src and dst are different arrays? 2) Can ArraySlice.copy be patched to use System_move_words after a check that the arrays are actually not the same? 3) Where is the code executed by System_move_words, and can this be fixed to correctly handle overlapping segments? Best, Peter

2 4

Large file support
by loganjerry＠gmail.com 13 Jun '13

13 Jun '13

Greetings, Fedora is planning to switch to btrfs as the default filesystem at some future point. This may cause problems for some 32-bit applications, because btrfs uses 64-bit inode numbers (see [1], for example). This can cause stat() calls to fail with EOVERFLOW, just because the inode number doesn't fit into the 32-bit stat structure, even if the caller doesn't care about the inode number. I'm attaching a candidate patch for polyml to avoid this issue. It enables large file support on systems where that makes sense, which builds with a 64-bit stat structure on 32-bit systems, and makes some types (such as off_t) larger. I seem to have a different version of automake than you, so I am not including the generated files in this patch. While you're changing stuff, though, may I suggest dropping AC_FUNC_SETVBUF_REVERSED from configure.ac? Autoconf complains that it is obsolete, and the one use of setvbuf() in the code ignores the results of this test anyway. References: [1] http://permalink.gmane.org/gmane.comp.file-systems.btrfs/10374 Regards, -- Jerry James http://www.jamezone.org/

2 1

Suspicious memset in 5.5
by loganjerry＠gmail.com 11 Jun '13

11 Jun '13

Greetings, I maintain the polyml package for the Fedora Linux distrubtion. I was just doing a build with the latest addition to polyml-5.5-fixes when I spotted this compiler output: elfexport.cpp: In member function 'virtual void ELFExport::exportStore()': elfexport.cpp:612:31: warning: argument to 'sizeof' in 'void* memset(void*, int, size_t)' call is the same pointer type '_memTableEntry*' as the destination; expected '_memTableEntry' or an explicit length [-Wsizeof-pointer-memaccess] memset(memTable, 0, sizeof(memTable)); So only the first pointer-length bytes of memTable are being cleared. Shouldn't that be: memset(memTable, 0, sizeof(*memTable) * memTableEntries); ? Regards, -- Jerry James http://www.jamezone.org/

2 1

crashes
by michael.norrish＠nicta.com.au 07 Jun '13

07 Jun '13

Using PolyML 5.5.0 as downloaded from Sourceforge, we can reliably produce: Exception- InternalError: indirect - invalid constant address raised while compiling Exception- InternalError: indirect - invalid constant address raised while compiling We can also regularly, but somewhat less reliably, produce hol.builder: gc_mark_phase.cpp:199: bool MTGCProcessMarkPointers::ForkNew(PolyObject*): Assertion `marker != 0' failed. Aborted (core dumped) where hol.builder is the name of our dumped heap. Are there any obvious things we can try to get around these problems? Thanks, Michael

2 1

(no subject)
by jesus-maria.aransay＠unirioja.es 24 May '13

24 May '13

Dear all, this is my first mail to the list, so first I wanted to say hello and kindly ask you for forgiveness if I break any conventions that usually apply in the list. We were doing some program performance testing with Poly ML 5.5 and we detected the following behavior when trying to use the information provided by "PolyML.timing" (I tried to produce a toy example). fun fact (n : int) = (if n = 0 then 1 else n * fact (n -1 )); PolyML.timing true; open TextIO; val foo = openOut ("foo"); open Int; output (foo, toString (fact (10000))); The last function returns a "run" time of "0.1" in a Linux machine, but "11.7" (approx) in our Windows machine, when the real time can be checked in both machines to be of the order of "0.1" (actually, the Windows machine in our case has much better hardware and is indeed faster in computations, this is the reason why we wanted to stick to it). Somehow, the timing information provided in the Windows machine is not correct. It scales to greater computations, where 200 seconds of real run time are shown in Windows as maybe 2000. In our Linux machine we have used the polyml version shipped with Isabelle 2013, whereas in the Windows machine we are using the binary version for Windows obtained from sourceforge. Are we doing anything wrong? Is this a known issue? Thanks for any hints, Jesus -- Jes?s Mar?a Aransay Azofra Universidad de La Rioja Dpto. de Matem?ticas y Computaci?n tlf.: (+34) 941299438 fax: (+34) 941299460 mail: jesus-maria.aransay at unirioja.es ; web: http://www.unirioja.es/cu/jearansa Edificio Luis Vives, c/ Luis de Ulloa s/n, 26004 Logro?o, Espa?a

2 2

FW: Memory Management across multiple threads using Futures Library
by michael.bradley＠hotmail.co.uk 29 Apr '13

29 Apr '13

Dear Lucas and Makarius,I have had some time to look at the debugging results, although I am not sure how to proceed. I have attached various files to show the output during multiple runs of the algorithm. (Each output was generated by a separate execution of the same function call)I believe that the heap's allocation of space adjustments are the key behaviour causing the process to slow down. In scenarios where the performance seems good, the "heapsize" debug report does not print anything. However, for a poor case, the space changes as depicted in the graph (22 times).As the GC reports suggest, the algorithm does produce a substantial amount of "garbage" due to its high rate of turn over (original description below), and I believe that the GC's very successful runs are causing the process to continually:Set the size of the heapRun the GC. Clears most of the heap, so reconsiders the size.The heap fills very quickly again and is forced to grow back.Possibly? I am not sure if this is important, but the GC reports a single stack overflow:...GC: Mark: Stack overflow. Rescan for 0x7f4f9a404b88GC: Mark: Rescanning from 0x7f55103fa6b0 to 0x7f55104ec540GC: Mark: Rescanning from 0x7f5023b68718 to 0x7f5023c48fc8...very early on in the algorithm's execution.Any advice you have is appreciated!Thanks again and best wishes,Michael Dear all, I am experiencing inefficiency while using the Futures library within PolyML. Parallel threads are being forced to 'sleep' for several seconds at a time for no clear reason, and I suspect it may be due to memory management between multiple threads. The test machine has 80GB RAM and 24 available cores. The parallel process works in roughly the same way as the Bag of Tasks Model with Replacements: (I'll refer to the distributor of tasks as the Controller, and other threads as Workers) 1. The Controller constructs an initial list of tasks.2. It sends the tasks to Workers in parallel, distributing across cores appropriately. Tasks are spawned by Future calls. They return a mixture of new tasks and results.3. It synchronises on all of the spawned tasks, organises them and repeats from (2) if any tasks remain. Tasks require a modest amount of memory and significant time to run, but there are 100,000s of them. The memory consumed can rise by 10GB in a few seconds but does not exceed the available RAM, and is held almost entirely by the Controller. The process can take minutes to run, but I see that spawned Futures in the program are required to sleep for the majority (~75%) of the time. The turnover in memory is very high as well, especially in the Controller thread, so calls to the garbage collector can reduce the RAM required dramatically. Initially, as the original problem size grows the speedup via parallelisation rises to a peak of around 6 times, requiring only a few GBs of RAM. However, as the problem size continues to rise and the problem should be easier to parallelise, the speedup falls to the point where a sequential algorithm evaluating tasks one at a time is more efficient. Artificial tests show that when virtually no memory is required, a speedup of over 10 times is quite easy to achieve. What I believe might be causing this is the allocation of segment sizes to threads in the heap. I believe that calls to the common memory pool to change the segment size are causing all threads to sleep unnecessarily. Does each thread currently have its own independent adaptive segment size, or are all threads required to use the same segment size? Do all threads have to pause if one segment size is being changed?I have timed the synchronisation phase above and it requires 10-100s of microseconds typically, so not accounting for the regular sleep times of several seconds. I know the threads are being paused mid-task computation, and I have tried increasing the heap size as well to no effect. Does anyone know what might be causing this behaviour?Best regards,Michael

1 0

Can't build mlton-20100608 with polyml on ARM
by adam＠spicenitz.org 27 Apr '13

27 Apr '13

Hi, I am trying to bootstrap mlton via polyml. This is working well on x86_64, but failing on ARM. I am getting this error: Exception- InternalError: fixupOffset: jump too far (16-bit offset) raised while compiling Exception- Fail "Exception- InternalError: fixupOffset: jump too far (16-bit offset) raised while compiling" raised Exception- Fail "Exception- InternalError: fixupOffset: jump too far (16-bit offset) raised while compiling" raised > # Error-Structure (Main) has not been declared Found near PolyML.shareCommonData Main.mainWrapped PolyML.export ("mlton-polyml", Main.mainWrapped) Error-Type error in function application. Function: PolyML.shareCommonData Main.mainWrapped : unit Argument: PolyML.export : string * (unit -> unit) -> unit Reason: Value being applied does not have a function type Found near PolyML.shareCommonData Main.mainWrapped PolyML.export ("mlton-polyml", Main.mainWrapped) Error-Structure (Main) has not been declared Found near PolyML.shareCommonData Main.mainWrapped PolyML.export ("mlton-polyml", Main.mainWrapped) Static Errors This seems to be a fundamental limitation of the interpreter. Is there any kind of workaround? Could the interpreter be extended to allow for longer jumps? Thanks, Adam

2 7

'Make_unsigned' was not declared in this scope
by mike.maul＠gmail.com 23 Apr '13

23 Apr '13

Getting this from SVN HEAD xwindows.cpp:2423:22: error: 'Make_unsigned' was not declared in this scope

2 1

← Newer
1
...
28
29
30
31
32
33
34
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Poly/ML