Poly/ML

polyml@lists.polyml.org

1 participants
698 discussions

Garbage collection issue with functional input streams
by pclayton＠taz.qinetiq.com 16 Sep '08

16 Sep '08

I have found a performance issue when using TextIO.StreamIO.input1 to read a functional stream. Looking at gc/non-gc times and using PolyML.profiling, it appears that garbage collection accounts for most of the time. There is some code below to demonstrate with stats that include comparison with SML/NJ. The profiling shows that readFromReader in basis/BasicStreamIO.sml is responsible for creating values that are being garbage collected. Looking at this code, I can see various things that would contribute to this garbage collection but nothing that is obviously problematic. Is it simply the case that overheads in the implementation mean that it is not suitable for a large number of small reads? Thanks, Phil (* `makeTextFile (filename, length)` generates a text file *) (* called `filename` of length `length` where every character *) (* is the digit '0'. *) local val l = 2048; val s = implode (List.tabulate (l, fn _ => #"0")); in fun makeTextFile (filename, length) = let open TextIO; val ostream = getOutstream (openOut filename); fun write n = if n < l then StreamIO.output (ostream, String.substring (s, 0, n)) else (StreamIO.output (ostream, s); write (n - l)); in write length; StreamIO.closeOut ostream end; end; (* `readTextFile filename` reads the file called `filename` *) (* one character at a time using a functional input stream *) (* and returns the time taken to read it. *) fun readTextFile filename = let open TextIO; val src = getInstream (openIn filename); fun read src = case StreamIO.input1 src of SOME (_, src') => read src' | NONE => (); val startTime = Timer.startCPUTimer (); in read src; (fn {sys, usr} => Time.+ (sys, usr)) (Timer.checkCPUTimer startTime) before StreamIO.closeIn src end; (* Create files and then read *) makeTextFile ("text-01MB", 1024 * 1024 * 1); makeTextFile ("text-02MB", 1024 * 1024 * 2); makeTextFile ("text-03MB", 1024 * 1024 * 3); makeTextFile ("text-04MB", 1024 * 1024 * 4); makeTextFile ("text-05MB", 1024 * 1024 * 5); readTextFile "text-01MB"; readTextFile "text-02MB"; readTextFile "text-03MB"; readTextFile "text-04MB"; readTextFile "text-05MB"; (* read times in seconds on Intel Core 2 Duo CPU T7500 @ 2.20GHz, 2GB *) (* Poly/ML 4.1.3 Poly/ML 5.2 SML/NJ 110.52 text-01MB 0.7 - 0.8 0.3 - 1.5 0.03 - 0.05 text-02MB 2.2 - 2.3 1.9 - 2.8 0.06 - 0.09 text-03MB 4.3 - 4.5 2.0 - 4.3 0.08 - 0.14 text-04MB 7.2 - 7.5 4.2 - 6.6 0.11 - 0.16 text-05MB 11.0 - 11.1 4.0 - 5.8 0.14 - 0.18 *) (* for large files, Poly/ML 4.1.3 can run out of store: *) makeTextFile ("text-40MB", 1024 * 1024 * 40); readTextFile "text-40MB"; (* Poly/ML 4.1.3 Poly/ML 5.2 SML/NJ 110.52 text-40MB out of store 101.4 1.1 - 1.2 4.1.3 gives the following message: Run out of store - interrupting console processes Exception- Interrupt raised *) The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this. Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes. QinetiQ Limited Registered in England & Wales: Company Number:3796233 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom http://www.QinetiQ.com/home/legal.html

3 4

Re: Poly/ML 5.2 and signals on older Linux systems
by David.Matthews＠prolingua.co.uk 09 Sep '08

09 Sep '08

Rob Arthan wrote: > David, > However, while I agree that my "fix" is a hack because it's working around > what looks like a bug in the old glibc, I am a little concerned that your > signal handling design is not POSIX-conformant. The POSIX specification of > sigaction includes the following statement: > > "The result of the use of sigaction() and a sigwait() function concurrently > within a process on the same signal is unspecified." > > I take this to mean that if you change the disposition of a signal using > sigaction() while you are waiting for it with sigwait() then the result is > unspecified. So the Cygwin behaviour would be conformant. The documentation > on signal() doesn't say anything about sigwait(), but it does say: > > "Use of this function is unspecified in a multi-threaded process." > > I think the POSIX-compliant way of implementing the ML signal function would > be to service ML requests to change the disposition of a signal by waking up > the signal detection thread and having it call sigaction. Thanks for pointing this out. I've also had another look at the documentation for sigwait and discovered that the Cygwin behaviour might be acceptable, not because of the interaction with sigaction but because the behaviour of sigwait when a signal is not blocked is undefined. As a result of all this I've revisited the whole mechanism for signal handling. The difficulty is that the pthread mutex and condition variable functions are not safe when used in a signal handler but it turns out that POSIX sem_post is safe. I've reworked the code to use a signal handler rather than sigwait and this appears to work on all the platforms I've tried, with the inevitable tweaks for the peculiarities of semaphores on Mac OS X and Cygwin. The new version is in CVS so you can try it out if you wish. I still have to get to the bottom of the other bug. Regards, David Copied to the mailing list for information.

2 2

InternalError: getSome raised while compiling
by tbourke＠cse.unsw.edu.au 28 Aug '08

28 Aug '08

I have a program that causes an InternalError in Poly/ML 5.2 on FreeBSD (but not MLton or SML/NJ). I haven't been able to test it under Linux. It can be reduced to these declarations: type int = Int.int; signature SIG = sig datatype t1 = T1 of int datatype t2 = T2 of { f : t1 } end; functor Fun () : SIG = struct datatype t1 = T1 of int datatype t2 = T2 of { f : t1 } end; structure Str1 = Fun () (*;*) structure Str2 : SIG = struct open Str1 end; fun g (Str2.T2 {f}) = (f=f); They compile if any of various changes are made: such as adding the semi-colon suggested above, removing the type int declaration, trying to shortcut Str2, removing the T1 label. Unfortunately, the corresponding changes are either difficult to make in the original program or do not seem to fix the problem. Sorry I haven't yet had time to look at Poly/ML myself. If a solution isn't readily suggested, I'll try to look harder over the weekend. Tim.

1 0

Unicode in Poly/ML?
by Michael.Norrish＠nicta.com.au 21 Aug '08

21 Aug '08

It is possible to emit Unicode (UTF-8 encoded say) strings in a Poly/ML program by emitting the appropriate sequence of bytes: Poly/ML 5.2 Release > print "\u00e2\u0088\u0080\n"; ? val it = () : unit But as far as Poly is concerned, this is actually a sequence of four characters, not two (the universal quantifier and the newline). Are there any plans to implement some sort of sensible WideChar signature? (The existing WideChar signature in the Basis is not really a good base on which to build good support here.) Michael.

4 4

Should -fno-strict-aliasing be in CXXFLAGS, too?
by lionel＠mamane.lu 18 Aug '08

18 Aug '08

Hi, Background: Achim Brucker and myself are packaging Poly/ML for Debian. I noticed that: 1) Compilation of file libpolyml/xwindows.cpp with gcc 4.2.3 gives several instances of: warning: dereferencing type-punned pointer will break strict-aliasing rules 2) libpolyml/Makefile.am has AM_CFLAGS = $(OSFLAG) -Wall -fno-strict-aliasing So I kinda guess that libpolyml/xwindows.cpp was supposed to be compiled with -fno-strict-aliasing, too, and you just forgot to put it in CXXFLAGS as well as CFLAGS? Or is the situation something else? -- Lionel

4 3

Re: Assertion failure in gc.cpp
by David.Matthews＠prolingua.co.uk 14 Aug '08

14 Aug '08

Rob Arthan wrote: > I am working on porting ProofPower to Poly/ML 5.2. I get the following > assertion failure when I run one of the tests for my parser generator. I can > reproduce the problem deterministically, but the circumstances in which it > occurs are obscure: at first glance it seems to depend on whether I am > calling "use" directly or via a function of my own, but it doesn't fail if I > avoid compiling my function twice. It seems very dependent on exactly how > things are compiled. > > slrp-ml: gc.cpp:878: virtual POLYUNSIGNED > ProcessUpdate::ScanAddressAt(PolyWord*): Assertion > `obj->ContainsNormalLengthWord()' failed. > Rob, Thanks for sending the test program. I finally managed to get to the bottom of this. The problem turned out to be the way that the heap was restored after calling "export". It would only have shown up in certain circumstances and only in a garbage collection after the export. Generally, export is the last thing that is called in a session which may explain why it didn't show up earlier. I've fixed it in CVS and your test now runs successfully. Let me know if you get this again although this assertion could be triggered by any number of different faults connected with the GC. Regards, David.

1 0

xwindows.xpp: deprecated conversion from string constant to 'char*'
by brucker＠spamfence.net 14 Aug '08

14 Aug '08

Hi, using a recent g++ version for compiling Poly/ML results in several warnings of the following form: xwindows.cpp: warning: deprecated conversion from string constant to 'char*' The warning is caused by implicit conversion from string constants (i.e., "foo") to non-constant char pointers. To this email, I attached a simple patch which should remove these warnings. The patch should be safe to apply as it either makes the casts explicit or changes some types from "char *" to "const char *". Please note that I could only test these modifications on my i386 box running Linux.... Achim

2 1

Release 5.2
by David.Matthews＠prolingua.co.uk 31 Jul '08

31 Jul '08

Timothy Bourke wrote: > I've just had some time to test the new version on FreeBSD (6.3-RELEASE). > > On Jun 3 at 15:14 +0100, David Matthews wrote: >> Changes to handling of signals by the Signal structure. Rather than >> forking a new thread to process each signal there is a single thread that >> executes all the signal handlers. This should improve the responsiveness >> to an asynchronous signals such as SIGINT. The original control-C handler >> has been removed and the Poly/ML read-eval-print loop now installs a simple >> handler for control-C that just generates an Interrupt exception. > > I found that the final polyimport -H 10 polytemp.txt kept crashing > with a segmentation fault. It seems that PTHREAD_STACK_MIN is not > enough space on FreeBSD 6.3. Adding 100 (found by trial and error) > fixes the problem as per the attached patch. Tim, Thanks for reporting this. I've installed FreeBSD 6.3 in an emulator and tested Poly/ML. It seems that PTHREAD_STACK_MIN is only 2k on FreeBSD whereas it is 16k on Linux. I've added a test for when it's less than 4k so that there is at least 4k for the stack. The idea was to try and use a smallish stack for this thread because it only calls a single function but there's no need to shave the stack space to an absolute minimum. It's likely to be rounded up to a page boundary anyway. I also fixed a few other things so that it compiles on FreeBSD without any other changes. Regards, David. Copied to the mailing list in case there are other FreeBSD users out there.

2 1

pretty printing oddities
by ldixon＠inf.ed.ac.uk 15 Jul '08

15 Jul '08

A while ago I grumbled about pretty printing of types in PolyML. I have just managed to condense my code into a sensibly viewable example which illustrates what I think the problem is: signature N = sig type T end; signature A = sig type T structure Ns : N sharing type Ns.T = T val mk : T val afoo : T -> T end; signature B = sig include A val bfoo : T -> T end; structure As : A = struct structure Ns = struct type T = string; end; type T = string val mk = "*" fun afoo s = s ^ "a"; end; structure Bs : B = struct open As; fun bfoo s = s ^ "b"; end; structure SafeBs :> B = Bs; Observe the output from PolyML for the signature SafeBs. It prints it out wrongly. And I think this is to do with the sharing constraint: without it, I get what I expect: structure SafeBs : sig structure Ns : N type T val afoo : SafeBs.T -> SafeBs.T val bfoo : SafeBs.T -> SafeBs.T val mk : SafeBs.T end However, with the sharing constraint, I get: structure SafeBs : sig structure Ns : N type T val afoo : A.T -> A.T val bfoo : A.T -> A.T val mk : A.T end I think, given that SafeBs is hiding the types, printing A.T is very confusing, one might even be tempted to say wrong. I would ideally like to have some programmatic control over the printing; perhaps choosing the left or right hand side of the last sharing constraint to be the name of the type that it printed. would be lovely if this was easy to fix - it would help my understanding of type errors enormously! :) cheers, lucas

1 0

polyml input, echo, pipes and PolyML.export oddity
by ldixon＠inf.ed.ac.uk 08 Jul '08

08 Jul '08

Hello, Perhaps this is something to do with my failure to understand unix pipes, but the following confuses me... I open poly from a shell and I type the following: fun loopy () = let val sopt = TextIO.inputLine(TextIO.stdIn); in case sopt of SOME s => (print s; loopy ()) | NONE => () end; PolyML.export ("foo", loopy); OS.Process.exit OS.Process.success; then I make this into a nice program call foo with: cc -o foo foo.o -L${POLYLIB} -lpolymain -lpolyml (${POLYLIB} is the local location of my poly libs) That does what I expect it to, it echos. However, the following misbehaves: echo 'fun loopy () = let val sopt = TextIO.inputLine(TextIO.stdIn); in case sopt of SOME s => (print s; loopy ()) | NONE => () end; PolyML.export ("foo", loopy); OS.Process.exit OS.Process.success;' | poly Somehow the "OS.Process.exit OS.Process.success;" becomes the first input whenever I foo... Is this my confusion, or is it really misbehaving? (PolyML5.2, Ubuntu 8.04) cheers, lucas

2 1

← Newer
1
...
52
53
54
55
56
57
58
...
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