Re: [Caml-list] How does OCaml update references when values are moved by the GC?
Jon Harrop wrote: I was hoping for a little more detail, of course. :-) How is the mapping from old to new pointers stored? With forwaring pointers. Just take 10 minutes to familiarize yourself with the standard stop© algorithm and everything will be clear: http://en.wikipedia.org/wiki/Cheney's_algorithm - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Generalized Algebraic Datatypes
Jacques Le Normand wrote: > Assuming I understand this syntax, the following currently valid type > definition would have two interpretations: [...] Don't take the syntax from my 2008 CUG talk too seriously, it was just a mock-up for the purpose of the talk. Besides, it's too early for a syntax war :-) This said, Coq could be another source of syntactic inspiration: it has several equivalent syntaxes for inductive type declarations (a superset of GADTs), one Haskell-like, others more Caml-like. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: About Cryptokit
> Does cryptokit support digesting Bigarrays? Currently no, but your PR#5005 made me think that it could be a good idea to add this functionality. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: Random segfaults / out of memory
So, is it really forbidden to release the global lock in a noalloc function? Yes. Actually, it is forbidden to call any function of the OCaml runtime system from a noalloc function. Explanation: ocamlopt-generated code caches in registers some global variables of importance to the OCaml runtime system, such as the current allocation pointer. When calling a regular (no-"noalloc") C function from OCaml, these global variables are updated with the cached values so that everything goes well if the C function allocates, triggers a GC, or releases the global lock (enabling a context switch). This updating is skipped when the C function has been declared "noalloc" -- this is why calls to "noalloc" functions are slightly faster. The downside is that the runtime system is not in a functioning state while within a "noalloc" C function, and must therefore not be invoked. The cost of updating global variables is small, so "noalloc" makes sense only for short-running C functions (say, < 100 instructions) like those from the math library (sin, cos, etc). If the C function makes significant work (1000 instructions or more), just play it safe and don't declare it "noalloc". Hope this helps, - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] testers wanted for experimental SSE2 back-end
Hello Dmitry, >> This is a call for testers concerning an experimental OCaml compiler >> back-end that uses SSE2 instructions for floating-point arithmetic.[...] > > I cannot provide any benchmark yet Too bad :-( I got very little feedback to my call: just one data point (thanks Gaetan). Perhaps most OCaml users interested in numerical computations have switched to x86-64bits already? At any rate, given such a lack of interest, this x86-32/SSE2 port isn't going to make it into the OCaml distribution. > but even not taking into account > the better register organization there are at least two areas where > SSE2 can outperform x87 significantly. > > 1. Float to integer conversion > Is quite inefficient on x87 because you have to explicitly set and > restore rounding mode. Right. The mode change makes the conversion about 10x slower on x87 than on SSE2. Apparently, float->int conversion is uncommon is numerical code, otherwise we'd observe bigger speedups on real applications... > 2. Float compare > Does not set flags on x87 so The SSE2 code is prettier than the x87 code, but this doesn't seem to translate into a significant performance gain, in my limited testing. > As for SSE2 backend presented I have some thoughts regarding the code > (fast math functions via x87 are questionable, Most x86-32bits C libraries implement sin(), cos(), etc with the x87 instructions, so I'm curious to know what you find objectionable here. > optimization of floating compare etc.) Where to discuss that - just > here or there is some entry in Mantis? Why not start on this list? We'll move to private e-mail if the discussion becomes too heated :-) - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] testers wanted for experimental SSE2 back-end
Mike Lin wrote:
I have a bunch of biological sequence analysis stuff that could be
interesting but I am already in x86-64 ("Wow! A 64 bit architecture!").
The above seems pretty clear but just to verify - I would not benefit
from this new back-end, right?
Right. Sorry for not mentioning this. The x86-64 bit code generator for
OCaml uses SSE2 floats, like all C compilers for this platform. The
experimental back-end I announced is for x86-32 bit. Some more Q&A:
Q: I have OCaml installed on my x86 machine, how do I know if it's 32
or 64 bits?
A: Do:
grep ^ARCH `ocamlopt -where`/Makefile.config
If it says "amd64", it's 64 bits with SSE2 floats.
If it says "i386", it's 32 bits with x87 floats.
If if says "ia32", it's the experimental back-end: 32 bits with SSE2 floats.
Q: If I compile from sources, which code generator is chosen by
default? 32 or 64 bits?
A: OCaml's configure script chooses whatever mode the C compiler
defaults to. For instance, on a 32-bit Linux installation, the 32-bit
generator is selected, and on 64-bit Linux installation, it's the
64-bit generator. Mac OS X is more tricky: 10.5 and earlier default
to 32 bits, but 10.6 defaults to 64 bits...
Will Farr wrote:
Oops. I just ran a bunch of tests on my Mac OS 10.6 system---does
that mean that I compared two sse2 backends? The ocaml-sse2 branch
definitely produced different code than the trunk, but that could
easily be due to any small difference in the two compilers, and not
due to a change of architecture.
It is quite possible you ended up with two 64-bit, SSE2-float back-ends.
Oups. Sorry for your time loss. And, yes, unrelated changes between
release 3.11.2 and the experimental sources I released (based on what
will become 3.12.0) can account for small speed differences.
- Xavier Leroy
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] testers wanted for experimental SSE2 back-end
Hello list, This is a call for testers concerning an experimental OCaml compiler back-end that uses SSE2 instructions for floating-point arithmetic. This code generation strategy was discussed before on this list, and I include below a summary in Q&A style. The new back-end is being considered for inclusion in the next major release (3.12), but performance testing done so far at INRIA and by Caml Consortium members is not conclusive. Additional results from members of this list would therefore be very welcome. We're not terribly interested in small (< 50 LOC), Shootout-style benchmarks, since their performance is very sensitive to code and data placement. However, if some of you have a sizeable (> 500 LOC) body of float-intensive Caml code, we'd be very interested to hear about the compared speed of the SSE2 back-end and the old back-end on your code. Switching to Q&A style: Q: Where can I get the code? A: From the SVN repository: svn checkout http://caml.inria.fr/svn/ocaml/branches/sse2 ocaml-sse2 Source-code only. Very lightly tested under Windows, so you might be better off testing under Unix. Q: What is this SSE2 thingy? A: An extension of the Intel/AMD x86 instruction set that provides, among other things, 64-bit float arithmetic instructions operating over 64-bit float registers. Before SSE2, the only way to perform 64-bit float arithmetic on x86 was the x87 instructions, which compute in 80-bit precision and use a stack instead of registers. Q: Why this sudden interest in SSE2? A: SSE2 has several potential advantages over x87, including: - The register-based SSE2 model fits the OCaml back-end much better than the stack-based x87 model. In particular, "let"-bound intermediate results of type "float" can be kept in SSE2 registers, while in the current x87 mode they are systematically flushed to the stack. - SSE2 implements exactly 64-bit IEEE arithmetic, giving float results that are consistent with those obtained on other platforms and with the OCaml bytecode interpreter. The 80-bit format of x87 produces different results and can causes surprises such as "double rounding" errors. (For more explanations, see David Monniaux's excellent article, http://hal.archives-ouvertes.fr/hal-00128124/ ) - Some x86 processors execute SSE2 instructions faster than their x87 counterparts. This speed difference was notable on the Pentium 4 in particular, but is much smaller on more recent processors such as Core 2. Note that x86-64 bits systems as well as Mac OS X already use SSE2 as their default floating-point model. SSE2 also has some potential disadvantages: - The instructions are bigger than x87 instructions, causing some increase in code size and potentially some decrease in instruction cache efficiency. - Computing intermediate results in 80-bit precision, like x87 does, can improve the numerical stability of poorly-conditioned float computations, although it doesn't make a difference for well-written numerical code. Q: Is SSE2 universally available on x86 processors? A: Not universally but pretty close. SSE2 made its debut in 2000, in the Pentium 4 processor. All x86 machines built in the last 4 years or so support SSE2, but pre-Pentium 4 and pre-Athlon64 processors do not. Q: So if you adopt this new back-end, OCaml will stop working on my trusty 1995-vintage Pentium? A: No. Under friendly pressure from our Debian friends, we agreed to keep the x87 back-end alive for a while in parallel with the SSE2 back-end. The x87 back-end is selected at configuration time if the processor doesn't support SSE2 or if a special flag is given to the configure script. Q: I observed a 20% (speedup|slowdown)! Should I tell the world about it? A: If your benchmark spends all its time in 10 lines of OCaml, maybe not. On such small codes, variations in code and data placement alone (without changing the instructions that are actually executed) can result in performance variations by 20%, so this is just experimental noise. Larger programs are less sensitive to this noise, which is why we're much more interested in results obtained on real OCaml applications. Finally, one micro-benchmark slowed down by a factor of 2 for reasons we couldn't explain. Q: What are those inconclusive results you mentioned? A: On medium-sized numerical kernels (e.g. FFT, Gaussian process regression), we've observed speedups of about 8% on Core 2 processors and somewhat higher on recent AMD processors. On bigger OCaml applications that perform floating-point computations but not exclusively, the performance difference was lost in the noise. Looking forward to interesting experimental results, - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria
Re: [Caml-list] Inside the mind of the inliner
I've been doing some experiments with the OCaml inliner, and have walked away from the process very confused. It seems like inlining can be prevented by very simple changes to the code of a function. The main surprise for me is that adding a quite trivial allocation of a list or a string literal defeats the inliner. Does anyone have a better understanding of what's going on here? I feel like my intuition for this stuff is terrible. The algorithm is very simple: a function is inlinable if 1- its code size (approximate) is below a certain threshold (governed by the -inline option) 2- and its body doesn't contain a function definition (fun x -> ..., let rec f x = ..., etc) nor a structured constant (string literal, [1;2;3], etc). The reason for 2- is that the inliner is too stupid to inline a function without duplicating the function definitions/structured constants contained within. Such a duplication can be very wasteful in code and static data size. (Cue the replies "but not if small enough!" in 3...2...1...now.) For your specific examples: (* Add in allocation of a list, not inlined *) let f x = ignore [1]; x + x let g x = f x + f x "[1]" is not a run-time allocation: its a structured constant, built at compile-time. Hence you run into case 2 above. (* allocate a string, not inlined *) let f x = ignore "foo"; x + x let g x = f x + f x Likewise (no allocation, but case 2). (* Call a function that includes an infix operator in prefix form, not inlined. *) let list = [1;2;3] let f x = x * List.fold_left (+) 0 list let g x = f x + f x Because (+) is really fun x y -> x + y, therefore case 2 again. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] dynamic link library path under mingw
I'm doing something wrong, but can't figure out what? Try setting the OCAMLRUNPARAMS environment variable to the value "v=256". The run-time system will then print additional debug messages concerning DLL searching and loading. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Alignment of data
I am working on some ppc architecture, and I realize that I have a (very) big slowdown due to bad alignment of data by ocamlopt. I need to have my data aligned in memory depending of the size of the data : floats are to be aligned on 8 bytes, int on 4 bytes, etc First, make sure that misalignment is really the source of your slowdown. The PowerPC processors I'm familiar with can access 4-aligned 8-byte floats with minimal overhead, while the penalty is much bigger for other misalignments. Indeed, the PowerPC calling conventions mandate that some 8-byte float arguments are passed on the stack at 4-aligned addresses, so that's strong incentive for the hardware people to implement those accesses efficiently. BUT, after verification, I remark that ocamlopt doesn't align as I need. I tried to use ARCH_ALIGN_DOUBLE, but it doesn't seem to be what I thought, and doesn't change anything for my needs. Is there ANY way to obtain what I need easily or at least quickly ? Data allocated in the Caml heap is word-aligned, where a word is 4 bytes on a 32-bit platform and 8 bytes on a 64-bit platform. This is deeply ingrained in the Caml GC and allocator, so don't expect to change this easily. What you can do, however: 1- Use the 64-bit PowerPC port. Everything will be 8-aligned then. 2- Use a bigarray instead of a float array. Bigarray data is allocated outside the heap, at naturally-aligned addresses. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: multicore wish
Gerd Stolpmann wrote: > It works with all types: > > https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/src/netsys/netsys_mem.mli > > look for init_value. It's non-released code yet. > > However, there are some problems: Values outside the heap do not support > the polymorphic comparison and hash functions. That's a hard limitation, > e.g. you cannot even compare two strings, or build a hash table with > strings as keys. That limits the usefulness of shared memory. In OCaml 3.11 and later, you can call caml_page_table_add(In_static_area, start, end) to inform the run-time system that the address range [start, end) contains well-formed Caml data that polymorphic primitives can safely work on. This should solve your problem. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] old Caml projects looking for new maintainers & contributors
Hello list, Prompted by Stefano Zacchiroli and Grégoire Henry's recent success in resurrecting CamlJava, I just migrated a number of my inactive OCaml side projects to the forge on ocamlcore.org: - CamlIDL (stub code generator for Caml/C interface) - CamlJava (low-level interface between Caml and Java through JNI) - CamlZIP (library to handle zip and gzip files) - Cryptokit (library of cryptographic primitives) - OCamlAgrep (library for string searching with errors) - OCamlMPI (Caml interface for the MPI parallel programming model) - SpamOracle (Bayesian mail filter) The purpose of this migration is to make it easy for others to participate in (or even take over) the maintenance and development of these projects, two tasks that I've very much neglected lately. So, if you find these projects useful and feel like participating in one way or another, just create an account on forge.ocamlcore.org and ask to join these projects. Also, the kind folks who package these projects are welcome to update their upstream URLs to point to the files on ocamlcore.org instead of my home pages: currently, they are identical, but further releases, if any, will be on ocamlcore.org. Cheers, - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Gc.compact surprisingly helpful
Aaron Bohannon wrote: > In order to prevent irregular GC pauses, I decided to try inserting > a call to Gc.compact once per loop. I was hoping the overall > throughput wouldn't suffer too badly. To my very pleasant surprise, > I found the throughput *increased* by about 2%!! So in a 15 second > run (with no idle time, as I said), it now does about 130 heap > compactions instead of 3 and gets better total performance because > of it, utterly defying my GC intuition. As Damien said, maybe the original code ran into a bad case of free list fragmentation which the compactor cured. But maybe the 2% is just measurement noise. Some of my favorite horror stories about timings: http://www-plan.cs.colorado.edu/diwan/asplos09.pdf "We see that something external and orthogonal to the program, i.e., changing the size (in bytes) of an unused environment variable, can dramatically (frequently by about 33% and once by almost 300%) change the performance of our program." http://compilers.iecc.com/comparch/article/96-02-165 [ Execution speed for the same binary varies by a factor of 2 depending on cache placement ] I have also personally observed speed differences of 20% just from inserting or deleting dead code in a program... - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Binding C libraries which use variable arguments (stdarg.h)
[Invoking a variadic C argument from OCaml] Assuming a Linux system, you could lazily generate the glue code and invoke dynamic linker on it. So the general case would be to call the code generator. On linux and x86, I could probably use an array where I would move by sizeof(some_type). I really want portability however (I want to use these bindings at least on windows too). It might be worth investigating the "libffi" library. If I guess correctly, it lets you synthesize calls to native C functions when the number and type of arguments are statically unknown. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] How to read different ints from a Bigarray?
Goswin von Brederlow wrote:
> I'm working on binding s for linux libaio library (asynchron IO) with
> a sharp eye on efficiency. That means no copying must be done on the
> data, which in turn means I can not use string as buffer type.
>
> The best type for this seems to be a (int, int8_unsigned_elt,
> c_layout) Bigarray.Array1.t. So far so good.
That's a reasonable choice.
> Now I define helper functions:
>
> let get_uint8 buf off = buf.{off}
> let set_uint8 buf off x = buf.{off} <- x
>
> But I want more:
>
> get/set_int8 - do I use Obj.magic to "convert" to int8_signed_elt?
Not at all. If you ask OCaml's typechecker to infer the type of
get_uint8, you'll see that it returns a plain OCaml "int" (in the
0...255 range). Likewise, the "x" parameter to "set_uint8" has type
"int" (of which only the 8 low bits are used).
Repeat after me: "Obj.magic is not part of the OCaml language".
> And endian correcting access for larger ints:
>
> get/set_big_uint16
> get/set_big_int16
> get/set_little_uint16
> get/set_little_int16
> get/set_big_uint24
> ...
> get/set_little_int56
> get/set_big_int64
> get/set_little_int64
The "56" functions look like a bit of overkill to me :-)
> What is the best way there? For uintXX I can get_uint8 each byte and
> shift and add them together. But that feels inefficient as each access
> will range check
Not necessarily. OCaml 3.11 introduced unchecked accesses to
bigarrays, so you can range-check yourself once, then perform
unchecked accesses. Use with caution...
> and the shifting generates a lot of code while cpus
> can usualy endian correct an int more elegantly.
>
> Is it worth the overhead of calling a C function to write optimized
> stubs for this?
The only way to know is to benchmark both approaches :-( My guess is
that for 16-bit accesses, you're better off with a pure Caml solution,
but for 64-bit accesses, a C function could be faster.
- Xavier Leroy
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] forbidden construct as right hand side of "let rec"
Mathias Kende wrote: > I need to write something like this : > > let f f i = if i = 0 then 1 else i * f (i - 1) > let rec g = f g > > Of course the compiler won't let me write it (even if the OCaml type > system is happy): > "This kind of expression is not allowed as right-hand side of `let rec'" In general, the best thing to do in this case is to switch to lazy evaluation: # let f f i = if i = 0 then 1 else i * Lazy.force f (i-1);; val f : (int -> int) Lazy.t -> int -> int = # let rec g' = lazy (f g');; val g' : (int -> int) Lazy.t = # let g = Lazy.force g';; val g : int -> int = # g 10;; - : int = 3628800 Lukasz Stafiniak wrote: > While we are at it, what is the best way to convert a "straight" list > into a cyclic list? > > i.e. convert > > let l = a::b::[] > > into > > let rec l = a::b::l > > (for arbitrary length lists). (The answer I recall from the archives > was using Obj.magic to mutate the [] in the original list). Obj.magic is not part of the OCaml language :-) Again, you can do that just fine using lazy lists instead of lists: type 'a lazylist = 'a lazylist_content Lazy.t and 'a lazylist_content = Nil | Cons of 'a * 'a lazylist Hope this helps, - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] public access to the SVN repository for OCaml
Hello list, This is an announcement for those of you who track the development of OCaml between releases. The OCaml development team recently switched from CVS to Subversion (SVN) as our version control system. Public read-only access to our new SVN repository is now available as described in the following page: http://caml.inria.fr/ocaml/anonsvn.en.html The old CVS repository on camlcvs.inria.fr is still accessible but no longer updated. It will go away in a few weeks. Subersively yours, - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Incremental linking
Dawid Toton wrote: I have lot of modules and they are compiled to native code. So I have .cmx and .o files and want to link them faster. Is is possible to make linking an associative operation acting on modules? [...] Documentation of ld says that files produced with --relocatable can be used as intermediate partially linked files. Can something like this be done with object code produced by ocamlopt? Yes. "ocamlopt -pack" actually calls "ld -r" underneath to consolidate several compilation units in a single .cmx/.o file. "ld -r" will resolve references between these compilation units. Gerd Stolpmann wrote: Well, you can link several .cmx files (and their accompanying .o files) to a .cmxa file (and an accompanying .a file): ocamlopt -a From a linking standpoint, "ocamlopt -a" is equivalent to "ar": it does not resolve any references, just concatenates individual .cmx/.o files in a single .cmxa/.a file. That can still speed up linking a bit, since reading one big .a file is faster than reading a zillion small .o files. Generally speaking, I'm somewhat surprised that linking time is an issue for Dawid. Modern Unix linkers are quite fast, and the additional link-time work that OCaml does is small. Let us know if you manage to narrow the problem. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] OC4MC : OCaml for Multicore architectures
Jon Harrop wrote: On Thursday 24 September 2009 13:39:40 Stefano Zacchiroli wrote: On Thu, Sep 24, 2009 at 12:52:24PM +0100, Jon Harrop wrote: The next steps are to get oc4mc into the apt repositories and build Uhm, I'm curious: how do you plan to achieve that? Good question. I have no idea, of course. :-) That would be suicidal. I definitely do not want to belittle the work of Philippe and his teammates -- what they did is an amazing hack indeed --, but you need to keep in mind the difference between a proof-of-concept experiment and a product. In a proof-of-concept experiment, you implement the feature want to experiment with and keep everything else as simple as possible (otherwise there is little chance that you'll complete the experiment). That's exactly what Philippe et al did, and rightly so: their GC is about the simplest you can think of, they didn't bother adapting some features of the run-time system, they target AMD64/Unix only, etc. Now they have a platform they can experiment with and make measurements on: mission accomplished. In a product, you'd need something that is essentially a drop-off replacement for today's OCaml and can run, say, Coq with at most a 10% slowdown. That's a long way to go (I'd say a couple of years of work). For example, single-generation stop-and-copy GC is known to have terrible performance (both in running time and in latency) for programs that have large data sets and allocate intensively. This is true in the sequential case and even worse in a stop-the-world parallel setting, by Amdahl's law. Note that the programs I mentioned above are exactly those that the Caml user community cares most about -- not matrix multiply nor ray tracers, Harrop's propaganda notwithstanding -- and those for which OCaml has been delivering top-class performance for the last 12 years -- again, Harrop's propaganda notwithstanding. On your way to a product, you'd need to independently-collectable generations (which means some work on the compiler as well), plus a parallel or even better concurrent major collector. And of course a lot more work on the runtime system and C interface to make everything truly reentrant while remaining portable. And probably some kind of two-level scheduler for threads. And after all that work you'd end up with an extremely low-level and unsafe parallel programming model that you'd need to tame by developing clever libraries that mere mortals can use effectively (Apple's Grand Central was mentioned on this thread; it's a good example)... In summary, Philippe and his coauthors do deserve a round of applause, but please keep a cool head. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Optimizing Float Ref's
I'm running OCaml 3.11.1, and I noticed something strange in some native code for matrix multiply today. The code was [...] [Local float ref being unboxed or not? ] You omitted the definition of "dims", but after adding the obvious definition, the float ref "sum" is indeed completely unboxed and is kept in a float register (on x86-64 bits) or stack location (on x86-32 bits). No "modify" takes place in the inner loop. So, I don't understand the problem you observed. Feel free to post a report on the BTS with a *complete* piece of code that reproduces the problem. But, I thought that float ref's were automatically unboxed by the compiler when they didn't escape the local context. Yes, if all uses of the float ref are unboxed, which is the case in your code. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] book "Le langage Caml"
A few months ago, there was a discussion on this list about "Le langage Caml", an early book on Caml (Light) programming written by Pierre Weis and I. The book was out of print, but the publisher, Dunod Éditions, graciously agreed to relinquish its rights and give them back to the authors. Pierre and I are therefore happy to announce that the full text of the book (2nd edition) is now available freely: http://caml.inria.fr/pub/distrib/books/llc.pdf There was a companion book, "Manuel de référence du langage Caml", which is the French translation of the Caml Light 0.7 reference manual. For completeness, we also made it available: http://caml.inria.fr/pub/distrib/books/manuel-cl.pdf Both texts are distributed under the Creative Commons BY-NC-SA license. Enjoy, - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Ocamlopt x86-32 and SSE2
This is an interesting discussion with many relevant points being made. Some comments: Matteo Frigo: Do you guys have any sort of empirical evidence that scalar SSE2 math is faster than plain old x87? I ask because every time I tried compiling FFTW with gcc -m32 -mfpmath=sse, the result has been invariably slower than the vanilla x87 compilation. (I am talking about scalar arithmetic here. FFTW also supports SSE2 2-way vector arithmetic, which is of course faster.) gcc does rather clever tricks with the x87 float stack and the fxch instruction, making it look almost like a flat register set and managing to expose some instruction-level parallelism despite the dependencies on the top of the stack. In contrast, ocamlopt uses the x87 stack in a pedestrian, reverse-Polish-notation way, so the benefits of having "real" float registers is bigger. Using the experimental x86-sse2 port that I did in 2003 on a Core2 processor, I see speedups of 10 to 15% on my few standard float benchmarks. However, these benchmarks were written in such a way that the generated x87 code isn't too awful. It is easy to construct examples where the SSE2 code is twice as fast as x87. More generally, the SSE2 code generator is much more forgiving towards changes in program style, and its performance characteristics are more predictable than the x87 code generator. For instance, manual elimination of common subexpressions is almost always a win with SSE2 but quite often a loss with x87 ... Pascal Cuoq: According to http://en.wikipedia.org/wiki/SSE2, someone using a Via C7 should be fine. Richard Jones: AMD Geode then ... Apparently, recent versions of the Geode support SSE2 as well. Low-power people love vector instruction sets, because it lets them do common tasks like audio and video decoding more efficiently, ergo with less energy. Sylvain Le Gall: If INRIA choose to switch to SSE2 there should be at least still a way to compile on older architecture. Doesn't mean that INRIA need to keep the old code generator, but should provide a simple emulation for it. In this case, we will have good performance on new arch for float and we will still be able to compile on old arch. The least complicated way to preserve backward compatibility with pre-SSE2 hardware is to keep the existing x87 code generator and bolt the SSE2 generator on top of it, Frankenstein-style. Well, either that, or rely on the kernel to trap unimplemented SSE2 instructions and emulate them in software. This is theoretically possible but I'm pretty sure neither Linux nor Windows implement it. David Mentre: Regarding option 2, I assume that byte-code would still work on i386 pre-SSE2 machines? So OCaml programs would still work on those machines. You're correct, provided the bytecode interpreter isn't compiled in SSE2 mode itself (see below for one reason one might want to do this). However, packagers would still be unhappy about this: packaged OCaml applications like Unison or Coq are usually compiled to native-code (the additional speed is most welcome in the case of Coq...). Therefore, packagers would have to choose between making these applications SSE2-only or make them slower by compiling them to bytecode. Dmitry Bely: [Reproducibility of results between bytecode and native] I wouldn't be so sure. Bytecode runtime is C compiler-dependent (that does use x87 for floating-point calculations), so rounding errors can lead to different results. That's right: even though it stores all intermediate float results in 64-bit format, a bytecode interpreter compiled in default x87 mode still exhibits double rounding anomalies. One would have to compile it with gcc in SSE2 mode (like MacOS X does by default) to have complete reproducibility between bytecode and native. Floating point is always approximate... I used to believe strongly in this viewpoint, but after discussion with people who do static analysis or program proof over float programs, I'm not so sure: static analysis and program proof are difficult enough that one doesn't want to complicate them even further to take extended-precision intermediate results and double rounding into account... To finish: I'm still very interested in hearing from packagers. Does Debian, for example, already have some packages that are SSE2-only? Are these packages specially tagged so that the installer will refuse to install them on pre-SSE2 hardware? What's the party line? - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Ocamlopt x86-32 and SSE2
Dmitry Bely wrote: > I see. Why I asked this: trying to improve floating-point performance > on 32-bit x86 platform I have merged floating-point SSE2 code > generator from amd64 ocamlopt back end to i386 one, making ia32sse2 > architecture. It also inlines sqrt() via -ffast-math flag and slightly > optimizes emit_float_test (usually eliminates an extra jump) - > features that are missed in the original amd64 code generator. You just passed black belt in OCaml compiler hacking :-) > Is this of any interest to anybody? I'm definitely interested in the potential improvements to the amd64 code generator. Concerning the i386 code generator (x86 in 32-bit mode), SSE2 float arithmetic does improve performance and fit ocamlopt's compilation model much better than the current x87 float arithmetic, which is a bit of a hack. Several options can be considered: 1- Have an additional "ia32sse2" port of ocamlopt in parallel with the current "i386" port. 2- Declare pre-SSE2 processors obsolete and convert the current "i386" port to always use SSE2 float arithmetic. 3- Support both x87 and SSE2 float arithmetic within the same i386 port, with a command-line option to activate SSE2, like gcc does. I'm really not keen on approach 1. We have too many ports (and their variants for Windows/MSVC) already. Moreover, I suspect packagers would stick to the i386 port for compatibility with old hardware, and most casual users would, too, out of lazyness, so this hypothetical "ia32sse2" port would receive little testing. Approach 2 is tempting for me because it would simplify the x86-32 code generator and remove some historical cruft. The issue is that it demands a processor that implements SSE2. For a list of processors, see http://en.wikipedia.org/wiki/SSE2 As a rule of thumb, almost all desktop PC bought since 2004 has SSE2, as well as almost all notebooks since 2006. That should be OK for professional users (it's nearly impossible to purchase maintenance beyond 3 years, anyway) and serious hobbyists. However, packagers are going to be very unhappy: Debian still lists i486 as its bottom line; for Fedora, it's Pentium or Pentium II; for Windows, it's "a 1GHz processor", meaning Pentium III. All these processors lack SSE2 support. Only MacOS X is SSE2-compatible from scratch. Approach 3 is probably the best from a user's point of view. But it's going to complicate the code generator: the x87 cruft would still be there, and new cruft would need to be added to support SSE2. Code compiled with the SSE2 flag could link with code compiled without, provided the SSE2 registers are not used for parameter and result passing. But as Dmitry observed, this is already the case in the current ocamlopt compiler. Jean-Marc Eber: >> But again, having better floating point performance (and >> predictable behaviour, compared to the bytecode version) would be a >> big plus for some applications. Dmitry Bely: > Don't quite understand what is "predictable behavior" - any generator > should conform to specs. In my tests x87 and SSE2 backends show the > same results (otherwise it would be called a bug). You haven't tested enough :-). The x87 backend keeps some intermediate results in 80-bit float format, while the SSE2 backend (as well as all other backends and the bytecode interpreter) compute everything in 64-bit format. See David Monniaux's excellent tutorial: http://hal.archives-ouvertes.fr/hal-00128124/en/ Computing intermediate results in extended precision has pros and cons, but my understanding is that the cons slightly outweigh the pros. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Custom blocks and finalization
Markus Mottl wrote: >> Let's have a look at byterun/globroots.c: > [snip] >> So... how could caml_remove_global_root() actually trigger a heap GC? > > It certainly doesn't, but it obviously manipulates runtime > datastructures which may not necessarily be in a state during > finalization where this is safe. I'd have to study the runtime code > in detail to learn more, but maybe the OCaml team can clarify this > issue more quickly? I foresee absolutely no problems with registering/unregistering global roots from a C finalizer. As the manual states, the big no-no in C functions attached to custom blocks is allocating in the heap, either directly or via a callback into Caml or by releasing the global lock. Within a finalizer, you should also refrain from raising an exception, as this would leave the GC is a bizarre state. But global roots operations are OK. As for not using the CAMLparam, etc macros in these functions: since these functions must not allocate, the macros are certainly not needed. I don't think that actually using them could cause a problem, but that would be silly anyway, so don't use them in this context. Hope this answers your question. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] arm backend
Joel Reymont wrote: Is the ARM backend (ocamlopt) usable and actively maintained? In brief: yes modulo ABI issues; yes. In more details: In OCaml 3.11 and earlier, the ARM port uses an old ABI (software conventions on using registers, etc). This ABI corresponds to the "arm" port of Debian; I don't know about other Linux distros. OCaml/ARM works like a charm on platforms supported by Debian/arm. I use it on a Linksys NSLU2. However, most embedded Linux/ARM platforms use a more recent, incompatible ABI called EABI. In Debian Lenny, it's available under the name "armel". I recently revised the OCaml/ARM port to adapt it to EABI and to software floating-point emulation. You can find it in the CVS trunk, and testing and feedback is most welcome. It works fine under Debian Lenny "armel". Floating-point performance is better than with the old port, because the latter used floating-point instructions that are no longer available on contemporary ARM processors and therefore had to be trapped and emulated by the kernel. In contrast, with soft floating-point, emulation is performed in user land by C library functions, which can also take advantage of vector float instructions if the processor supports them. Concerning the iPhone, it is not supported out of the box by 3.11 nor by the CVS trunk code. For 3.11, several patches have been mentioned on this list; it would be great if someone with iPhone development experience could combine them and publish a unified patch. For the CVS trunk code, it seems we are getting close: as far as I could see, MacOSX/ARM uses EABI plus Apple's "signature" approach to dynamic linking. However, I haven't yet succeeded in running Apple's iPhone SDK compilers from the command-line. (It looks like one of those Microsoft SDK's that assume everyone is developing from the vendor-supplied IDE...) Again, I welcome feedback and patches from iPhone development experts. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Ocamlopt code generator question
For amd64 we have in asmcomp/amd64/proc_nt.mlp: (* xmm0 - xmm15 100 - 115 xmm0 - xmm9: Caml function arguments xmm0 - xmm3: C function arguments xmm0: Caml and C function results xmm6-xmm15 are preserved by C *) let loc_arguments arg = calling_conventions 0 9 100 109 outgoing arg let loc_parameters arg = let (loc, ofs) = calling_conventions 0 9 100 109 incoming arg in loc let loc_results res = let (loc, ofs) = calling_conventions 0 0 100 100 not_supported res in loc What these first_float=100 and last_float=109 for loc_arguments and loc_parameters affect? My impression is that floats are always passed boxed, so xmm registers are in fact never used to pass parameters. And float values are returned as a pointer in eax, not a value in xmm0 as loc_results would suggest. The ocamlopt code generators support unboxed floats as function parameters and results, as well as returning multiple results in several registers. (Except for the x86-32 bits port, because of the weird floating-point model of this architecture.) You're right that the ocamlopt "middle-end" does not currently take advantage of this possibility, since floats are passed between functions in boxed state. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] C wrappers for Ocaml functions
So I am investigating packing my nice Ocaml code into a library and
writing C bindings so that I can talk to it. [...]
In particular, I have found
none that cover how to obtain pointers to OCaml function return values
that are not strings or ints, how to store them in C-land, and how to pass
them back to Ocaml as parameters.
You have two choices: copy the contents of the OCaml data structure to
a C data structure, e.g. an OCaml tuple or record of ints can be
copied to a C struct, field by field; or, treat the OCaml value as an
opaque type on C's side.
The code you posted attempts to do the second approach, but you cannot
just take a Caml "value" and give it to arbitrary C code: the Caml GC
will lose track of the value and reclaim it (or copy it elsewhere) at
the first opportunity.
Instead, you need to wrap the Caml value in a C memory block and
register it with the GC using caml_register_global_root. Then, an
explicit free function must be provided in the C interface to
unregister with the GC and to free the wrapper. See the
attached modification of your ht_wrap.c example. It should put you on
the right tracks.
5. And this is how I am attempting to compile it. Note that error I'm
getting here is in link. If I add "-lm" it gets less noisy but still is
mad at me. Why am I having to add math library?
Because the Caml runtime system needs it. As Dmitry wrote, the
simplest way to build your example is:
ocamlopt -output-obj -o ht_lib.o ht.ml
ocamlopt -c ht_wrap.c
gcc -o htt ht_test.c ht_lib.o ht_wrap.o -L`ocamlopt -where` -lasmrun -lcurses
-lm
Hope this helps,
- Xavier Leroy
#include
#include
#include
#include
#include "ht.h"
struct hashtable {
value v;
};
static struct hashtable * ht_alloc (value v)
{
struct hashtable * wrapper = malloc(sizeof(struct hashtable));
if (wrapper == NULL) return NULL;
wrapper->v = v;
caml_register_global_root(&(wrapper->v));
return wrapper;
}
void ht_free (struct hashtable * ht)
{
caml_remove_global_root(&(ht->v));
free(ht);
}
struct hashtable * ht_create (void) {
static value *create_closure = NULL;
if (create_closure == NULL)
create_closure = caml_named_value("create");
return ht_alloc(caml_callback(*create_closure, Val_unit));
}
void ht_add (struct hashtable * ht, char *key, int val) {
static value *add_closure = NULL;
if (add_closure == NULL)
add_closure = caml_named_value("add");
caml_callback3(*add_closure, ht->v, caml_copy_string(key), Val_int(val));
}
void ht_mem (struct hashtable * ht, char *key) {
static value *mem_closure = NULL;
if (mem_closure == NULL)
mem_closure = caml_named_value("mem");
caml_callback2(*mem_closure, ht->v, caml_copy_string(key));
}
void ht_remove (struct hashtable * ht, char *key) {
static value *remove_closure = NULL;
if (remove_closure == NULL)
remove_closure = caml_named_value("remove");
caml_callback2(*remove_closure, ht->v, caml_copy_string(key));
}
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] OCaml and Boehm
> Is the OCaml runtime Boehm-safe? That is, can it be run with Boehm > turned on and traversing OCaml's heap? (So that the OCaml heap can > provide roots to Boehm.) I conjecture the answer is "yes", although it's hard to tell for sure without a precise specification of what is/is not OK with the Boehm-Demers-Weiser collector. >From the standpoint of this collector, OCaml's heap is just a set of large-ish blocks allocated with malloc() (*) and containing a zillion pointers within those blocks. OCaml doesn't play any dirty tricks with pointers: no xoring of two pointers, no pointers represented as offsets from a base, no pointers one below or one above a malloc-ed block. Most pointers are word-aligned but we sometimes play tricks with the low 2 bits. Of course, almost all Caml pointers point inside those malloc-ed blocks, not to the beginning, but I'm confident that the B-D-W collector can handle this, otherwise it would fail on pretty much any existing C code. This said, I agree with Basile that what you're trying to achieve (coexistence between several GCs) is risky, and that a design based on message passing and separated memory spaces would be more robust, if feasible. - Xavier Leroy (*) In 3.10 and earlier releases, OCaml sometimes used mmap() instead of malloc() to obtain these blocks. Starting from 3.11, malloc() is the only interface OCaml uses to obtain memory from the OS. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Re: LLC book [was: Questions]
It could be nice to translate it in English, at least to have a larger base of readers, and adapt the examples from Caml Light to Objective Caml (I don't know how much the syntaxes differ though) The syntax is very close for the subset of Caml used in the book. Right. Parts of the standard library changed, though. However, judging from the lack of availability of this book even in French, there might an issue in the agreement between the authors (Leroy & Weis) and the publisher. I'm suspecting the authors are unable to re-publish the book elsewhere. The publisher (Dunod) holds all rights except for an English translation (Pierre Weis and I reserved those rights). There is a procedure to ask the publisher to relinquish its rights if it decides not to print the book again, but that procedure can take up to 1 year (!). All in all, I'm not sure it's worth the effort to resurrect this old text, but if a group of motivated volunteers arise, let's discuss it privately. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] questions
I saw Xavier Leroy teach caml at the CNAM in france, and he know how to teach. Just for the record: I never lectured at CNAM, but probably you're thinking of Pierre Weis, who taught a great "programming in Caml" course there for several year. That course was the main starting point for our book "Le langage Caml". Regards, - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] questions
> There must be some reason why the manual and other materials on the > official site are of such poor quality. I've thought a bit about it, and > the only reason I see is that the authors do not have a feel for what it > takes to learn/understand/use that language. They obviously know it all > through, but that's still far removed from being able to explain it to > someone else. I don't know, of course, how it is that one understands > something "well" yet is not able to explain it to somebody else. To me, > that's very fragile knowledge. Because we are autistic morons who lack your rock-solid knowledge, if I properly catch your (rather insulting) drift? At the very least, you're confusing "to be able" with "to intend to". The "tutorial" part of the OCaml reference manual was a quick job targeted at readers who already know functional programming and just want a quick overview of what's standard and what's different in OCaml. Maybe that shouldn't be titled "tutorial" at all. Teaching functional programming in OCaml to beginners is a rather different job, for which they are plenty of good books already. Most of them happen to be in French for various reasons: O'Reilly's refusal to publish the English translation of the Chailloux-Manoury-Pagano book; the Hickey-Rentsch controversy, etc. But, yes, some talented teachers invested huge amounts of time in writing good intro to Caml programming books. Don't brush their efforts aside. One last word to you, that Xah Lee troll, and anyone else on this list: if you're not happy with the existing material, write something better. Everyone will thank you and you'll get to better appreciate the difficulty of the task. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] PowerPC 405
Just to complement Basile's excellent answers: > Do you know if it is possible to compile caml code on a PowerPC 405 > from the Vertex 4 family ? > We'd like to put this processor in a FPGA. On the Caml's website, > it is written "PowerPC" but is it only for Macintosch ? Not just Macintosh: PowerPC/Linux is also supported and works very well. > Yes, it will run Linux. It will have the uclibC or even the lib C. Then you're in good shape. I would expect a basic OCaml system to work with uclibC, although a number of external libraries might not. With GNU libC, everything will work but watch out for code size: glibc is big! > The best case is to run native code for better performance. We'd > like to cross-compile for the PowerPC. Setting up OCaml as a cross-compiler is a bit of a challenge at the moment. As a prerequisite, you'll need a complete cross-compilation environment for C: cross-compiler, cross-binutils, libraries and header files for your target. It sounds obvious but in my experience that's quite hard to get right. Then, there is a bit of configuration magic to be done on the OCaml side. Write back for help if you're going to follow this way. A perhaps simpler alternative would be to compile on a bigger PowerPC/Linux platform. An old Mac would be handy for this, but you can also use a Sony Playstation 3 (if you happen to have one around for, ahem, R&D purposes) after installing YellowDog Linux on it. - Xavier "doing lots of R&D with my PS3" Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Récursivité terminale
Je voudrais savoir s'il existait un moyen de transformer une fonction récursive non terminale en fonction récursive terminale avec Caml. [ Translation: is there a way to transform a non-tail-recursive function into a tail-recursive function? ] A technique that always works is to convert your function to continuation-passing style. The resulting code is hard to read and not particularly efficient, though. It is possible to do better in a number of specific cases. Functions operating over lists can often be made tail-rec by adding an "accumulator" parameter and reversing the accumulator at the end. For instance, List.map f l (not tail-rec) can be rewritten as List.rev (List.rev_map f l) (tail-rec). For more complex data structures than lists, Huet's zippers can often be used for the same purpose. Happy Googling, - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Google summer of Code proposal
2- OCaml's strategy is close to optimal for symbolic computing. Is MLton not several times faster than OCaml for symbolic computing? No, only in your dreams. If there was a Caml or SML compiler that was twice as fast as Caml on codes like Coq or Isabelle/HOL, everyone (me included) would have switched to that compiler a long time ago. MLton can probably outperform Caml on some symbolic codes, but not by a large factor and not because of data representation strategies (but rather because of more aggressive inlining and the like). - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Google summer of Code proposal
I would like to develop LLVM frontend to Ocaml language. LLVM does participate in GSoC. LLVM do not mind to developed a ocaml frontend as LLVM GSoC project. I want to discuss details with you before I will make an official proposal to LLVM. [...] Do authors of ocaml has something to say about the idea? Da. A number of things, actually. 1- I know of at least 3, maybe 4 other projects that want to do something with OCaml and LLVM. Clearly, some coordination between these efforts is needed. 2- If you're applying for funding through a summer of code project, you need to articulate good reasons why you want to combine OCaml and LLVM. "Ocaml is cool, LLVM is cool, so OCaml+LLVM would be extra cool" is not enough. "It will generate PIC-16 code" isn't either. Run-time code generation could be a good enough reason, but you still need to weigh the development cost of the LLVM approach against, for example, hacking the current OCaml code generator so that it emits machine code in memory instead of assembly code. 3- A language implementation like OCaml breaks down in four big parts: 1- Front-end compiler 2- Back-end compiler and code emitter 3- Run-time system 4- OS interface Of these four, the back-end is not the biggest part nor the most complicated part. LLVM gives you part 2, but you still need to consider the other 3 parts. Saying "I'll do 1, 3 and 4 from scratch", Harrop-style, means a 5-year project. To get somewhere within a reasonable amount of time, you really need to reuse large parts of the existing OCaml code base. 4- From a quick look at LLVM specs, the two aspects that appear most problematic w.r.t. Caml are exception handling and GC interface. LLVM seems to implement C++/Java "zero-cost" exceptions, which are known to be quite costly for Caml. (Been there, done that, in the early 1990s.) I regret that LLVM does not provide support for alternate implementations of exceptions, like the C-- intermediate language of Ramsey et al does: http://portal.acm.org/citation.cfm?id=349337 The big issue, however, is GC interface. There are GC techniques that need no support from the back-end: stack maps and conservative collection. Stack maps are very costly in execution time. Conservative GC like the Boehm-Weiser GC is already much better. But for full efficiency, back-end support is required. LLVM documents a minimal interface to produce stack maps and make them available to the GC at run-time: http://llvm.org/docs/GarbageCollection.html The first thing you want to investigate is whether this interface is enough to support an exact, relocating collector such as OCaml's. According to http://www.nabble.com/Garbage-collection-td22219430.html Gordon Henriksen did succeed in interfacing OCaml's GC with LLVM. Maybe there is still some more work to do here, in which case I recommend you look into this first. 6- Here is a schematic of the Caml compiler. (Use a fixed-width font.) | | parsing and preprocessing v Parsetree (untyped AST) | | type inference and checking v Typedtree (type-annotated AST) | | pattern-matching compilation, elimination of modules, classes v Lambda / \ /\ closure conversion, inlining, uncurrying, v \ data representation strategy Bytecode \ \ Cmm | | code generation v Assembly code In my opinion, the simplest approach is to start at Cmm and generate LLVM code from there. Starting at one of the higher-level intermediate forms would entail reimplementing large chunks of the OCaml compiler. Note that Cmm is quite close to the C-- intermediate language mentioned earlier, so there is a lot to learn from Fermin Reig's experience with an OCaml/C-- back-end. 7- To finish, I'll preventively deflect some likely reactions by Jon Harrop: "But you'll be tied to OCaml's data representation strategy!" Right, but 1- implementing you own data representation strategy is a lot of work, especially if it is type-based, and 2- OCaml's strategy is close to optimal for symbolic computing. "But LLVM assembly is typed, so you must have types!" Just use int32 or int64 as your universal type and cast to appropriate pointer types in loads or stores. "But your code will be tainted by OCaml's evil license!" It is trivial to make ocamlopt dump Cmm code in a file or pipe. (The -dcmm debug option already does this.) Then, you can have a separate, untainted program that reads the Cmm code and transforms it. "But shadow stacks are the only way to go for GC interface!" No, it's probably the worst approach performance-wise; even a c
Re: [Caml-list] caml trading
(I know I should let this thread die, but I can't resist!) Mike Lin wrote: > But seriously, I'd suggest that your company could augment its > excellent technical outreach efforts to the > academic/engineering/free-software crowd with some education about > why you are proud of your business. Wise words indeed. May I also suggest some investment counseling targeted to the working Caml programmer? After all, it's in Jane Street's best interest to make sure that key Caml developers don't blow their little savings on mutual funds once presented to them as "very safe, you can't lose with this one"... - Xavier "but I didn't have any Madoff, or so my bank tells me" Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] The new OCaml book (Objective Caml Programming Language by Tim Rentsch)
> Overall, I can't help seeing that any author who isn't known on this > list ends up with a questionable book -- first Smith and now Rentsch. > Perhaps the elders should form a book vetting committee? Well, the power to decide is in the hands of publishers (initially) and customers (later). But I can assure you that reputable publishing houses like Springer, Cambridge University Press or MIT Press do sollicit opinions from academics like me and take them into account. Their area editors attend major conferences like Principles of Programming Languages and it's always a pleasure to chat with them. But there isn't much that can be done with less reputable publishers and self-publishing, as Alexy remarked. Coming back to the Hickey/Rentsch book(s), I feel deeply sad about the mess that is unfolding on this list. I proofread a draft of Jason Hickey's book, at his request, and found it very good and just what the OCaml community is still missing: a well-written, English-language book on Caml appropriate both as a reference and as teaching material. (I'm not criticizing the other books in english on OCaml -- thanks God they exist! -- just noting that they don't quite fit this exact purpose.) What we now have is lawsuit material... I sincerely hope some kind of agreement can still be found at this point. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] speeding up matrix multiplication (newbie question)
> I'm working on speeding up some code, and I wanted to check with > someone before implementation. > > As you can see below, the code primarily spends its time multiplying > relatively small matrices. Precision is of course important but not > an incredibly crucial issue, as the most important thing is relative > comparison between things which *should* be pretty different. You need to post your matrix multiplication code so that the regulars on this list can tear it to pieces :-) >From the profile you gave, it looks like you parameterized your matrix multiplication code over the + and * operations over matrix elements. This is good for genericity but not so good for performance, as it will result in more boxing (heap allocation) of floating-point values. The first thing you should try is write a version of matrix multiplication that is specialized for type "float". Then, there are several ways to write the textbook matrix multiplication algorithm, some of which perform less boxing than others. Again, post your code and we'll let you know. > Currently I'm just using native (double-precision) ocaml floats and > the native ocaml arrays for a first pass on the problem. Now I'm > thinking about moving to using float32 bigarrays, and I'm hoping > that the code will double in speed. I'd like to know: is that > realistic? Any other suggestions? It won't double in speed: arithmetic operations will take exactly the same time in single or double precision. What single-precision bigarrays buy you is halving the memory footprint of your matrices. That could result in better cache behavior and therefore slightly better speed, but it depends very much on the sizes and number of your matrices. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Lazy and Threads
Victor Nicollet wrote: > I'm working with both lazy expressions and threads, and noticed that the > evaluation of lazy expressions is not thread-safe: Yaron Minsky wrote: > At a minimum, this seems like a bug in the documentation. The > documentation states very clearly that Undefined is called when a value > is recursively forced. Clearly, you get the same error when you force a > lazy value that is in the process of being forced for the first time > It does seem like fixing the behavior to match the current documentation > would be superior to fixing the documentation to match the current behavior. It's not just the Lazy module: in general, the whole standard library is not thread-safe. Probably that should be stated in the documentation for the threads library, but there isn't much point in documenting it per standard library module. As to making the standard library thread-safe by sprinkling it with mutexes, Java-style: no way. There is one part of the stdlib that is made thread-safe this way: buffered I/O operations. (The reason is that, owing to the C implementation of some of these operations, a race condition in buffered I/O could actually crash the whole program, rather than just result in unexpected results as in the case of pure Caml modules.) You (Yaron) and others recently complained that such locking around buffered I/O made some operations too slow for your taste. Wait until you wrap a mutex around all Lazy.force operations... More generally speaking, locking within a standard library is the wrong thing to do: that doesn't prevent race conditions at the application level, and for reasonable performance you need to lock at a much coarser grain, again at the application level. (That's one of the things that make shared-memory programming with threads and locks so incredibly painful and non-modular.) Coming back to Victor's original question: > Aside from handling a mutex myself (which I don't find very elegant for > a read operation in a pure functional program) is there a solution I can > use to manipulate lazy expressions in a pure functional multi-threaded > program? You need to think more / tell us more about what you're trying to achieve with sharing lazy values between threads. If your program is really purely functional (i.e. no I/O of any kind), OCaml's multithreading is essentially useless, as you're not going to get any speedup from it and would be better off with sequential computations. If your program does use threads to overlap computation and I/O, using threads might be warranted, but then what is the appropriate granularity of locking that you'd need? A somewhat related question is: what semantics do you expect from concurrent Lazy.force operations on a shared suspension? One thread blocks while the other completes the computation? Same but with busy waiting? (if the computations are generally small). Or do you want speculative execution? (Both threads may evaluate the suspended computation.) There is no unique answer to these questions: it all depends on what you're trying to achieve... - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] What is a future of ocaml?
> [*] INRIA: Are you interested in handling control of http://ocaml.org > to OcamlCore? I think we (Red Hat) can kick in some money to pay a > graphic designer and a user interface specialist to work on a good > looking site that appeals to beginners and directs people to the > necessary resources. That sounds like an interesting offer indeed. We'd have to discuss actual contents of the site, but, yes, this is an area where outside help would be welcome. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Why does value restriction not apply to the empty list ?
Antoine Delignat-Lavaud wrote: > I chose to solve the problem of polymorphic references by adding value > restriction* to my inferer, using ocaml to check my results. > Not knowing whether the empty list should be considered a value or an > expression, I copied Ocaml's behavior and made it a value. Yes, the empty list is a value, like all other constants. > As a result, my inferer gave the following expression the integer type : > let el = [] in if hd el then 1 else hd el ;; > which is the expected result since el has polymorphic type 'a list > but does not look right because it is used as both a bool list and an > int list. It is perfectly right. The empty list can of course be used both as a bool list and an int list; that's exactly what parametric polymorphism is all about. Richard Jones wrote: > But the same if statement within a function definition causes an error: > > # let f el = > if List.length el > 0 then (List.hd el)+(int_of_string (List.hd el)) else > 0;; > ^^ > This expression has type int but is here used with type string This is Hindley-Milner polymorphism at work: only "let"-bound variables can have polymorphic types, while function parameters are monomorphic. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Shared libraries with ocamlopt callable from C (without main())?
> = $ cat ./main.c =
> #include
> #include "libadd5wrapper.h"
> int main (int argc,char **argv){
>printf("Gimme - %d \n", add5wrapper());
Should be add5wrapper(argv) -- as gcc's warnings told you.
>return 0;
> }
>
> Now I try to BUILD the whole thing:
> [...]
> Number 4 is where it breaks. I get a ton of errors and this is where
> it ends for me. Because # 4 is also the point where I definitely have
> no idea what I'm doing.
Two things:
- You're not linking in add5-prog.o as far as I can see
- In static mode, the Unix linker is very picky about the relative
order of -lxxx arguments on the command-line. For more information,
see the Info pages for GNU ld. You probably don't need -static anyway.
The following works:
ocamlopt -output-obj add5.ml -o add5-prog.o
gcc -I`ocamlc -where` -c add5wrapperlib.c
gcc -c main.c
gcc -o mainprog.opt main.o add5wrapperlib.o add5-prog.o \
-L`ocamlc -where` -lasmrun -ldl -lm
Add "-static" to the last line if you know you really need it.
Hope this puts you back on tracks.
- Xavier Leroy
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Freeze in 64-bit Windows Num module
> I have an issue with using the Num module in my Win64 OCaml compile. > Whenever I try to operate on numbers that are too large it will lock up. I'll try to look into this, but it would help if you'd submit a problem report through the bug tracking system. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] fork() and threads in ocaml 3.11
> The program > > open Unix > > let os = (let f = open_process_in "uname -sr" in > let answer = input_line f in > ignore (close_process_in f); answer) > > let _ = > let f () = > print_endline os > in > let t = Thread.create f () in > Thread.join t > > hangs on my FreeBSD 7.0. This could be the same problem reported under MacOS X as PR#4666 in the bug tracker. Apparently, MacOS X doesn't allow a process having multiple threads to perform an exec*() system call. Maybe FreeBSD has the same limitation. > I tried ocaml from yesterday's CVS, but it does not help. The "release 3.11" branch of the CVS contains a tentative fix for PR#4666. It isn't yet propagated to the CVS trunk. You can get this branch using "cvs co -r release311". Hope this helps, - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] OCaml version 3.11.0 released.
> It is our pleasure to celebrate the 51st birthday of Eric S. Raymond > by releasing OCaml version 3.11.0. [...] > Please note: at this time it is only available as source and as > binary for Mac OS X on Intel processors. Other binary versions > will be added to the Web site next week. Binary distributions for Windows (MSVC and Mingw toolchains) are now available from the usual place: http://caml.inria.fr/download.html Enjoy, - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] OCaml 3.11.0 release candidate
> So far our tests have compiled and run successfully in most platforms > [1] excepting Windows 64 bits (but it's the first time I attempt to > compile in this architecture). I am getting this error message: There are two problems with Windows 64 that I forgot to fix before this RC1 release; this is one of them. A patch is available at http://gallium.inria.fr/~xleroy/ocaml-3.11rc1-win64.patch The CVS release branch contains this fix. Regards, - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Tutorial example for nat dynlink
Hello Yves, > I have been trying to build a small example "hello world" program > using native dynlink, but I don't manage to make it work. Could > please send me some advice? The issue here is that when Dynlink.loadfile is called, module Toto is not yet completely evaluated, therefore it is not yet visible to dynamically-loaded code. The solution is just to split your main program in two modules: Toto containing what your plugin needs to see, and Totomain performing the dynlink. Then, it'll work just fine. Cheers, - Xavier ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] OCaml 3.11.0 release candidate
Damien Doligez wrote: > We are closing in on version 3.11.0. A Release Candidate is now available. > The release candidate is available here: > < http://caml.inria.fr/pub/distrib/ocaml-3.11/ > The documentation for 3.11 is also available from the same place. The HTML manual can be browsed online at http://caml.inria.fr/pub/docs/manual-ocaml-311/index.html Enjoy, - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] OCaml version 3.11.0+beta1
David Allsopp wrote: > The Win64 port is listed as requiring Windows XP 64 or Server 64 - is 64 bit > Windows Vista not included in the list because it's not supported or because > it's not been tested with it? Because it hasn't been tested with Vista 64. But I'm pretty sure that if Microsoft's PSDK for x86-64 works well on Vista 64, so should OCaml. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: Road to native windows OCaml...
>> Nasm and masm syntaxes differ. You cannot simply interchange them. > > What I meant was that caml would generate one more asm syntax, it already > supports two (masm and gas). ... and it's already a major pain, with quite a bit of code duplication between the masm and gas code emitters. The world doesn't need yet another symtax for x86 assembly language. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] OCaml version 3.11.0+beta1
>> Native dynlink used to work on Mac OS X < 10.5 (x86 only). The new >> linker in 10.5 does not support linking shared libraries with non-PIC >> code. It is still possible to use the old linker, called ld_classic, >> but some libraries (like X11) does not work, so this has been disabled >> in the configure script. >> >> The clean solution to make natdynlink work on recent Mac OS X systems >> (beside convincing Apple to support the old behavior of their linker >> in their new implementation) is to change OCaml's x86 backend so that >> it produces only PIC code (this has been done for the AMD64 port). I >> don't think there is currently any plan to work on that. > > Ouch, this makes it almost a dead end for us. I can offer some time to > help in this effort, working in the port, or providing feedback. The > native dynlink and toplevel are, at least to me, the killer features in > 3.11, but adding another hole for Mac OS X intel (in addition to not > supporting x86_64) does not seem like the best choice for an > increasingly popular architecture. Well, we'd very much like to support native dynlink on OS X 10.5, but Apple is not helping in the least by crippling their linker compared with the one in 10.4. If anyone from Apple is on this list, feel free to contact us at [EMAIL PROTECTED] for more information on this regression. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] [ANN] OCamlSpotter: OCaml compiler extension for source browsing
>> I have written a small compiler patch called ocamlspotter. It extends >> -annot option and records all the variable definition locations, so >> that we can jump from variable uses to their definitions easily from >> editors such as emacs. > > You have completely blown my mind. I was thinking about this very > idea about 10 minutes ago in my car, and *blam* there it is. I should > think about some other, more profitable ideas... > > I would suggest submitting this as a patch for inclusion. I've heard > there are going to be enhancements to the .annot format in 3.11 so > it's not unprecedented. >From what I've heard, there's also an OCaml summer of code project that enriched the info found in .annot files. So, it's certainly time to discuss extensions to .annot files, but let's do that globally, not one at a time. It is probably too late for inclusion in 3.11, but as long as these extensions are backward compatible, inclusion in bugfix releases can be considered. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] ocamlopt generates binaries with executable stacks
>> Note that in 3.11, the "configure" script will have options to specify >> how to call the assembler (for ocamlopt-generated assembly code and >> for the hand-written asm files in the runtime system). So it might be >> sufficient to configure the Gentoo packages with e.g. >> >> configure -as "as --noexecstack" -aspp "gcc -c -Wa,--noexecstack" >> >> This could be one of the rare cases where addressing the issue at the >> level of the packages is safer than by changing the source distribution. > > Fair enough. I'll check this out and get back if it doesn't work. For the record, in the working sources that will be released as 3.11, I added the "no exec note" in assembly files for Linux/x86 and Linux/AMD64, but no other platforms so far because I can't test on them. If someone with access to other Linux platforms is willing to experiment and confirm that it works, let me know. This said, the configure trick above might do the job just as well. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] 3.11?
> I asked about 3.11 and when it would be released, and the answer at > that time was in late August: > > http://groups.google.com/group/fa.caml/tree/browse_frm/thread/15126f960406e056/531fda06c1da700e > > Obviously August (2008?) is slipping away. Do we have any updates on > the status of 3.11? We made good progress during the summer, but a bit of polish and code review is needed before the release. > The reason I ask is that the Fedora 10 beta deadline has slipped > because of the security intrusion two weeks ago, which means there is > a slim possibility of getting 3.11 into Fedora 10, if the release > happens real soon. I'm afraid 3.11 will not be ready in time for Fedora 10. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] 'Nondeterministic' evaluation wrt exceptions
> Could you give me some advice how to evaluate really all applications > that precede throwing an exception? I'm not sure I fully understand what you're trying to achieve, but I'm reminded of "futures", a construct for parallel computation that was popular in the Lisp world in the 80's. The classic reference is Halstead's Multilisp system: http://www.cs.wisc.edu/~fischer/cs538.s04/multilisp.pdf In a nutshell, a future is like a lazy value, but the underlying computation is evaluated speculatively in parallel with the main program, rather than waiting until its value is needed as in the case of lazy evaluation. Hope this might help, - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Heaps size problems with "caml_alloc_small" in foreign function interfaces
> I'm having a problem where sometimes a call to "caml_alloc_small" from C > results in a segmentation fault. If I increase the size of the stack > using OCAMLRUNPARAM=s=1000k then I don't get the crash anymore. It seems > strange that I have to increase the size of the heap manually like this. It's probably a root registration problem. These are very sensitive to the times when GC is triggered, which themselves are sensitive to the heap sizes and memory behavior of your program. > If I want to increase the size of the heap in C how do I do this? Could > I write a "safe" caml_alloc_small which first checks to see if there is > enough memory and then increases the heap size if not? Don't try to hack around the real problem, but do make available a repro case, no matter how large, on a Web site or as attachment to a problem report on the bug tracking system, so that others can have a look at it. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Problem of compilation with ocamlopt
> I made some code wich compil without any problem with ocamlc. > When I try to compil with ocamlopt on a first computer where the version > of ocamlopt 3.09.1 I have the following message: Please submit a proper bug report on the bug tracking system, including code that reproduces the issue. Make sure to mention the OS and the architecture (x86 or x86-64). I'll look into it. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] thousands of CPU cores
J C wrote: > I know that Caml team wanted to see if many-core shared-memory systems > were going to stick around before bothering with Caml development that > takes advantage of them. > Well, it looks like they are here to stay, after all: > http://news.cnet.com/8301-13924_3-9981760-64.html As others mentioned already, nothing in this news item talks about shared memory parallelism. There are good reasons to think that the illusion of shared memory cannot be maintained in the presence of hundreds of computing elements, even using cc-NUMA techniques (i.e. hardware emulation of shared memory on top of high-speed point-to-point links). Look at GPUs, which are the closest we have today to a manycore system: 128 cores are available today, more is in preparation, but the programming model is definitely not SMP. I had the opportunity to discuss this with Anwar Ghuloum, the Intel principal engineer quoted in the Cnet article (and the driving force behind Intel's joining the Caml consortium, by the way). His group is definitely not committed to shared-memory approaches, but instead investigates high-level data-parallel programming models with a strong functional flavor that can be mapped both to shared memory and non-shared memory systems. (http://techresearch.intel.com/articles/Tera-Scale/1514.htm) So, I am as convinced as ever that shared mutable data is a terrible programming model for parallelism, because 1- it's awfully low-level, error-prone and non-compositional, and 2- interesting parallel hardware doesn't implement it anyway. (Examples: clusters, GPUs, the Cell processor.) At best, shared memory is a low-level implementation technique which, like manual memory management, pointer arithmetic and self-modifying code, is best hidden in the OS and language runtime system, but should never be exposed to the programmer. The interesting question that this community should focus on (rather than throwing fits about concurrent GC and the like) is coming up with good programming models for parallelism. I'm quite fond of message passing myself, but agree that more constrained data-parallel models have value as well. As Gerd Stolpmann mentioned, various forms of message passing can be exploited from OCaml today, but there is certainly room for improvement there. Jon Harrop wrote: > Today's biggest shared-memory supercomputers already have thousands > of cores. ??? All these supercomputers are clusters. Sylvain Le Gall wrote: > There is also the fact that using multi process allow you to go further > than the memory limit per process (3GB for Linux/ 1GB for Windows). With > the actual increase of amount of RAM, this can be an issue. The correct solution to this issue isn't to artificially split your program in multiple processes, but to move to 64-bit architectures. You would be hard pressed to buy a desktop PC today that isn't 64-bit capable. Linux x86-64 works beautifully. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Building a Set module for elements of a Map
Fabrice Marchant wrote: > Please consider a functor F that takes as input the output signature of a Map. > > Here is the only way I see to declare a Set module whose elements type are Map.S.key : > > module F ( M : Map.S ) = struct > module MKeySet = > Set.Make ( struct type t = M.key let compare = compare end ) > end Jean-Christophe Filliâtre replied: > Using Pervasives.compare instead of a user-defined comparison function > may even be incorrect. (Suppose the intended comparison function should > identify (x,y) and (y,x), for instance; obviously, Pervasives.compare > will not.) > > A possible solution to your problem is to have functor F taking instead > a module for keys as argument, and then to build module M inside F; thus > it would look like: > > module F(K : OrderedType) = struct > module M = Map.Make(K) > module MKeySet = Set.Make(K) > ... > end Jean-Christophe is right that Pervasives.compare is not the solution. Yet another alternative is to parameterize F over both a Map and a Set, adding a sharing constraint to ensure that they work on compatible data types: module F (M: Map.S) (MKeySet: Set.S with type elt = M.key) = struct ... end - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Strange behaviour of string_of_float
>> If you can serialize to binary, you can acheive what you want by
>> serializing the 64 bits integers you get with Int64.bits_of_float and
>> applying Int64.float_of_bits to the integers you deserialize.
>
> Actually, for serialization, I strongly reccommend first using
> classify_float to split off and handle NaNs, Infinities, etc., then
> using frexp to split the float into a fraction and exponent. The
> exponent is just an int, and the fractional part can be multiplied by,
> say, 2^56 and then converted into an integer.
>
> The advantage of doing things this way, despite it being slightly more
> complicated, is two fold: one, it gaurentees you the ability to recovery
> the exact binary value of the float, and two, it sidesteps a huge number
> of compatibility issues between architectures- IIRC, IEEE 754 specifies
> how many bits have to be used to represent each part of the float, but
> not where they have to be in the word.
The only architecture I know where this problem could occur is the old
(pre-EABI) ABI for ARM, which has "mixed-endian" floats. But the
implementation of Int64.{bits_of_float,float_of_bits} goes to some
length to rearrange bits as expected, i.e. with the sign bit in the
most significant bit of the int64, followed by the exponent bits,
followed by the mantissa bits in the least significant bits of the
int64.
So, the case analysis on the float that Brian suggests is a bit of an
overkill, and I strongly suggest using the result of
Int64.bits_of_float as the exact, serializable representation of a
Caml float.
- Xavier Leroy
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] ocamlopt generates binaries with executable stacks
> I posted a patch which should fix the issue that ocamlopt generates > binaries with executable stacks: > > http://caml.inria.fr/mantis/view.php?id=4564 > > However this patch affects every assembly target, far more than I > could possibly test. Could people using OCaml on non-Linux platforms > have a look at the patch, or even test it for me? I'm pretty sure this patch is Linux-specific. My fear is that it might be specific to particular versions of binutils and/or particular Linux distributions... I smell a portability nightmare! Note that in 3.11, the "configure" script will have options to specify how to call the assembler (for ocamlopt-generated assembly code and for the hand-written asm files in the runtime system). So it might be sufficient to configure the Gentoo packages with e.g. configure -as "as --noexecstack" -aspp "gcc -c -Wa,--noexecstack" This could be one of the rare cases where addressing the issue at the level of the packages is safer than by changing the source distribution. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Release date for 3.11?
> I'm sure the answer will be 'when it's ready', but is there a release > date (month / year / ...) for 3.11 or release candidates of 3.11? I'd like to release by late August, provided no show-stopping problems show up by then. - Xavier Leroy ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
