Re: [Caml-list] Re: Logging
On 2010-12-21 13:16, Gregory Bellier wrote: 2010/12/21 Sylvain Le Gall sylv...@le-gall.net: There is also Lwt_log. http://ocsigen.org/lwt/doc/api/Lwt_log.html To be more verbose, I have two processes with two different effective uid If both processes start out as root then you can open the logfile before dropping privileges. Best regards, --Edwin ___ 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: optimize div to right shift (NOT!)
On Mon, 13 Dec 2010 12:33:33 + Jonathan Kimmitt jonat...@kimmitt.co.uk wrote: A C compiler would optimize this to a right shift. Changing that to 'Int64.shift_right n 1' speeds up the code. Sorry to be a pedant, but this is not correct. The optimisation is only possible when the arguments are unsigned integers That particular program never used negative integers. which I don't think is specifiable when working in OCAML You are right, there is no way to tell ocaml that. # Int64.shift_right (-2L) 1;; - : int64 = -1L (So far, so good) # Int64.div (-1L) 2L;; - : int64 = 0L (Good) # Int64.shift_right (-1L) 1;; - : int64 = -1L (Duh) It is still possible to avoid the division, gcc generates this: movq%rdi, %rax shrq$63, %rax addq%rdi, %rax sarq%rax Or a better example with division by 8: leaq7(%rdi), %rax testq %rdi, %rdi cmovns %rdi, %rax sarq$3, %rax And division by non-power of two integers can optimized by replacing it with multiplication with its inverse (which gcc and llvm don't do for signed divisions, only for unsigned ones): http://www.hackersdelight.org/HDcode/magic.c.txt http://www.hackersdelight.org/HDcode/magicu.c.txt Best regards, --Edwin ___ 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: Value types (Was: [Caml-list] ocamlopt LLVM support)
On Sun, 12 Dec 2010 18:01:13 - Jon Harrop j...@ffconsultancy.com wrote: Török Edwin wrote: Do you really need to use Int64 for that though? Won't the 63-bit version do? I'm running 32-bit. That explains it, in a 32-bit chroot my modified version is still slow. I thought that 32-bit systems are not that relevant anymore (except for Windows, but then people start moving to 64-bit there also). I am unable to reproduce your results. Here, the time falls from 24s to 19.5s (using ocamlopt 3.12.0 on Intel x86) which is still 26× slower than HLVM. Sorry, I'm actually using an Opteron x86 (logged in from an Intel x86!). Do you still have 'idiv' in the compiled code? See my attached assembly, and compare it with yours please. I was doing the test on 64-bit, with ocamlopt 3.11.2 and 3.12.0. I get what appear to be calls to C code: camlCollatz__collatzLen_1030: subl$8, %esp .L103: movl%eax, 4(%esp) movl%ebx, 0(%esp) pushl $camlCollatz__10 pushl %ebx movl$caml_equal, %eax callcaml_c_call Yes, that is quite bad. I don't know how OCaml's code generator works, but it looks like it calls the C implementation if the CPU doesn't support the operation directly. And since this is 32-bit you need all the extra pushes and movs to do actually call something. If only it could inline those calls, then it could optimize away most of the overhead (LLVM would help here again). FWIW the original code took 2.8 seconds here, so only 4x slower (this is an AMD Phenom II x6 1090T CPU). It probably depends how fast/slow the 'idiv' is on your CPU. The performance of idiv is irrelevant here. The bottleneck may be those C calls but I don't understand why they are being generated. I think for the same reason gcc has __udivdi3 in libgcc: there is no direct way of executing a 64-bit divide on a 32-bit machine, and it saves code space to do it in a function. However that doesn't make much sense for mul and add, which don't need that many instructions to implement on 32-bit. Cheers, Jon. ___ 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: Value types (Was: [Caml-list] ocamlopt LLVM support)
On Sun, 12 Dec 2010 20:09:00 +0100 Benedikt Meurer benedikt.meu...@googlemail.com wrote: On Dec 12, 2010, at 16:55 , Török Edwin wrote: [...] Problem #2: Int64.div n 2 - idiv instruction. A C compiler would optimize this to a right shift. Changing that to 'Int64.shift_right n 1' speeds up the code. This is easy to fix in ocamlopt (see attached patch ocamlopt-natint.patch), by applying the same optimizations already used for constant int's to constant natint's (Int64 is Nativeint on 64bit). Nice patch. I definitely agree that what can be fixed in ocamlopt's high-level opts should be fixed there, rather than hope that LLVM will just do everything. [...] One advantage of using LLVM is that it would notice arithmetic optimizations like this and perform it itself (even if you use the boxed representation). In case of x86-32, it won't, simply because LLVM will be presented with the calls to caml_int32_* functions. I was thinking that the runtime could be compiled to .bc, and then they would get inlined and optimized away at link time. That is overkill for something as simple as integer arithmetic, but could be useful for more complicated runtime functions (or C bindings). You'd need to change the Cmm code instead (changing the low-level stuff is straight-forward as demonstrated). I agree that not emitting those C calls in the first place is better. For 64bit targets, see attached patch. This doesn't mean that LLVM wouldn't be useful (in fact, I've just started an LLVM backend for ocamlopt). Great! If you notice some more optimizations missed by ocamlopt while working on it, could you write up a list of those? I think I suggested earlier in this thread that LLVM could be used in two ways: write a backend with it, or port some of the LLVM optimizations to ocamlopt. Maybe it'd be good to write some documentation on ocamlopt's internals, and how one can add more optimizations there. Something simple like what is the IR format (like LLVM's langref), how you perform the optimizations (what is the equivalent of LLVM's passes), and what helper modules can you use (what is the equivalent of LLVM's analysis) would suffice for a start. Does something like this exist already? But it is important to note that LLVM is not the solution to everything. As the name implies, it's low level, it does a few higher level optimizations for C, but these are special cases (and somewhat ugly if you take the time to read the code). It won't make a faster OCaml magically, just like it didn't make a faster Haskell by itself. I could go on by quoting common Harrop jokes like you need types in the low-level IR, etc. trying to tell him that this is simply wrong; but after reading through the Caml/LISP mailing list archives (thanks for the pointers by several readers), I'm pretty much convinced that Jon simply decided to end his war against LISP just to start a new one against ocamlopt. If anyone is serious about ocamlopt with LLVM, feel free to contact me (tho, my time is limited atm). I wouldn't have much time to dedicate to this, so I can't say I'm serious about it. AFAICT LLVM's OCaml bindings are only good for generating LLVM IR from OCaml, not for actually performing transformations on it (there is no binding to retrieve the type of a value for example). I'll probably be looking into fixing that in the near future, and this may indirectly help your LLVM backend (if you intend to write OCaml specific transformations on the LLVM IR). Best regards, --Edwin ___ 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: Value types (Was: [Caml-list] ocamlopt LLVM support)
On Sun, 12 Dec 2010 22:05:34 - Jon Harrop jonathandeanhar...@googlemail.com wrote: Edwin wrote: AFAICT LLVM's OCaml bindings are only good for generating LLVM IR from OCaml, not for actually performing transformations on it (there is no binding to retrieve the type of a value for example). I'll probably be looking into fixing that in the near future, and this may indirectly help your LLVM backend (if you intend to write OCaml specific transformations on the LLVM IR). That's a lot of work. Wouldn't it be preferable to do the passes on the OCaml side and focus on generating high quality LLVM IR? Yes, that is probably a better approach (generating the optimized IR in the first place). Best regards, --Edwin ___ 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: ocamlopt LLVM support (Was: [Caml-list] OCamlJIT2 vs. OCamlJIT)
On Sun, 5 Dec 2010 17:37:32 +0100 Benedikt Meurer benedikt.meu...@googlemail.com wrote: Two main areas for now: The GC interface and the exception handling. LLVM's exception support is really limited; the GC support is better and more generic. I don't know how to implement the OCaml exception model within LLVM w/o adding a lot of special case stuff to LLVM itself (mentioned in my original post); if there would be a way to easily extend LLVM with special exception models, other projects could plug in their models. There is a discussion on the LLVM mailing list about changing exception handling in LLVM: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-December/036692.html If the new model is not generic enough to support OCaml's model, then I think now would be a good time to describe on the LLVM ML what OCaml's model would need and the proposal doesn't cover. Best regards, --Edwin ___ 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: ocamlopt LLVM support (Was: [Caml-list] OCamlJIT2 vs. OCamlJIT)
On Fri, 3 Dec 2010 15:41:41 +0200 Eray Ozkural examach...@gmail.com wrote: Is there IPA in LLVM? I didn't know that. See createStandardLTOPasses and the UnitAtATime part of createStandardModulePasses: http://llvm.org/svn/llvm-project/llvm/trunk/include/llvm/Support/StandardPasses.h Also http://llvm.org/svn/llvm-project/llvm/trunk/include/llvm/Transforms/IPO.h http://llvm.org/svn/llvm-project/llvm/trunk/lib/Analysis/IPA I doubt they'll be able to figure out everything on their own though, the frontend should probably add some extra info. For example by adding some function attributes, or some metadata about the high-level types. I see that LLVM has a metadata based TBAA, but right now it is for C/C++, so I'm not sure it could take advantage of all the properties of a functional language. It'd probably be better if an OCamlAA was written (perhaps building on the already existing TBAA, or improving that) that takes advantage of immutable data structures and OCaml's type system. Best regards, --Edwin ___ 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 GC [was Is OCaml fast?]
On Thu, 2 Dec 2010 13:57:23 +0100
Damien Doligez damien.doli...@inria.fr wrote:
On 2010-11-29, at 23:27, Török Edwin wrote:
This seems to be in concordance with the smaller minor heap = more
minor collections = slower program observation, since it is:
smaller minor heap = more minor collections = more major slices =
major slices can't collect long-lived objects = slower program
(long lived objects are sweeped too many times).
So more minor collections = higher cost for a major slice
This is a bit naive, because the size of a major slice depends on the
amount of data promoted by the corresponding minor GC. A smaller
minor heap promotes less data each time, so you get more major
slices, but they are smaller. The total amount of work done by the
major GC doesn't change because of that. It only changes because a
bigger minor heap gives more time for data to die before being
promoted to the major heap.
Thanks for the explanation.
Is there a way I could use more than 2 bits for the color?
I thought to try excluding some objects from collection if they failed
to get collected for a few cycles (i.e. just mark them black from the
start). Tried modifying Wosize_hd, and Make_header, but it is not
enough, anything else I missed?
I think OCaml's GC should take into account how successful the last
major GC was (how many words it freed), and adjust speed
accordingly: if we know that the major slice will collect next to
nothing there is no point in wasting time and running it.
So this formula should probably be changed:
p = (double) caml_allocated_words * 3.0 * (100 + caml_percent_free)
/ Wsize_bsize (caml_stat_heap_size) / caml_percent_free / 2.0;
Probably to something that also does:
p = p * major_slice_successrate
The success rate is already taken into account by the major GC. In
fact a target success rate is set by the user: it is
caml_percent_free / (100 + caml_percent_free)
Thanks, that is probably what I had in mind, but adjusting it doesn't
work as I initially expected.
and the major GC adjusts its speed according to this target. If the
target is not met, the free list is emptied faster than the GC can
replenish it, so it gets depleted at some point and the major heap
is then extended to satisfy allocation requests. The bigger major
heap then helps the major GC meet its target, because the success rate
is simply (heap_size - live_data) / heap_size, and that gets higher
as heap_size increases.
I didn't do the math, but I think your modification would make the
major heap size increase without bound.
Yeah, I've been experimenting, and unless I put a lower bound on
'p' (like half of initial one) it used way too much memory (sure it was
also faster, but then it is also faster by not running the GC at all
which is not good).
Which parameter do you think could be automatically tuned to accomodate
bursts of allocations? Maybe major_heap_increment (based on recent
history of heap expansions, and promoted words)?
BTW I was also looking at ways to speed up mark_slice and sweep_slice,
(which is not easy since it is mostly optimized already).
Found a place where GCC is not smart enough though. Attached patch
improves GC sweep_slice by 3% - 10% in ocamlopt, depending on CPU (3%
Intel, 10% AMD Phenom II X6). Should I open a bug and attach it?
Using gcc -O3 gives would sometimes give the same benefits, but I
don't really trust -O3, -O2 is as far as I would go. See here for all
the details: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46763
[speaking of which why is the GC compiled with -O, is -O2 too risky
too?]
P.S.: minor_heap_size got bumped in 3.12 branch, so it is now greater
than major_heap_increment. Is that intended?
Best regards,
--Edwin
diff -ru /home/edwin/ocaml-3.12.0+rc1/byterun//major_gc.c ./major_gc.c
--- /home/edwin/ocaml-3.12.0+rc1/byterun//major_gc.c 2009-11-04 14:25:47.0 +0200
+++ ./major_gc.c 2010-12-02 17:02:38.0 +0200
@@ -286,21 +286,25 @@
{
char *hp;
header_t hd;
+ /* speed opt: keep global in local var */
+ char *gc_sweep_hp = caml_gc_sweep_hp;
caml_gc_message (0x40, Sweeping %ld words\n, work);
while (work 0){
-if (caml_gc_sweep_hp limit){
- hp = caml_gc_sweep_hp;
+if (gc_sweep_hp limit){
+ hp = gc_sweep_hp;
hd = Hd_hp (hp);
work -= Whsize_hd (hd);
- caml_gc_sweep_hp += Bhsize_hd (hd);
+ gc_sweep_hp += Bhsize_hd (hd);
+ PREFETCH_READ_NT(gc_sweep_hp);
switch (Color_hd (hd)){
case Caml_white:
+ caml_gc_sweep_hp = gc_sweep_hp;
if (Tag_hd (hd) == Custom_tag){
void (*final_fun)(value) = Custom_ops_val(Val_hp(hp))-finalize;
if (final_fun != NULL) final_fun(Val_hp(hp));
}
-caml_gc_sweep_hp = caml_fl_merge_block (Bp_hp (hp));
+gc_sweep_hp = caml_fl_merge_block (Bp_hp (hp));
break;
case Caml_blue:
/* Only the blocks of the free-list are blue
Re: [Caml-list] OCamlJIT2 vs. OCamlJIT
On Tue, 30 Nov 2010 09:36:07 +0100 Benedikt Meurer benedikt.meu...@googlemail.com wrote: Hello everybody, I did some final work on OCamlJIT2, and compared the result to OCamlJIT. The performance measures are presented in the following tech report (skip straight to section 4 for the performance results): http://arxiv.org/abs/1011.6223 In short: Performance measured on a P4 Northwood (no long mode, plain x86) 2.4GHz. OCamlJIT2 beats OCamlJIT by a factor of 1.1 to 2.0 in every benchmark, and - rather surprising - was even able to beat ocamlopt in the number crunching benchmark (probably an issue with the x86 backend of ocamlopt). Looks like this happens only on Pentium4: on Core2 and Xeon ocamlopt is still faster on almabench.unsafe, or did I miss something? As mentioned by Xavier Leroy and others previously, we probably went as far as we could go in the direction of JITting the byte-code virtual machine, while preserving its general stack-based nature and instruction set. Moving even further means translating the byte-code to some intermediate form suitable for use with standard compilation techniques; but as we saw earlier, in an LLVM-based prototype, the compilation overhead increases dramatically and the benefit of JIT compilation vanishes. An LLVM-based backend would still be interesting for static compilation, where compile times don't matter much. Did you try comparing an LLVM-based backend with ocamlopt? If it is faster could some of the LLVM passes be ported to ocamlopt's backend? Best regards, --Edwin ___ 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] OCamlJIT2 vs. OCamlJIT
On Tue, 30 Nov 2010 18:01:28 +0100 bluestorm bluestorm.d...@gmail.com wrote: On Tue, Nov 30, 2010 at 11:55 AM, Benedikt Meurer benedikt.meu...@googlemail.com wrote: LLVM backend for ocamlopt is a totally different story. You'd have to start with the Ulambda or the Cmm intermediate representation, while a JIT approach starts with the byte-code representation (not necessarily, but that was the case for our approach). However, I'm not sure there would be any immediate benefit from using LLVM as code generator backend for ocamlopt, since ocamlopt already does a quite good (and fast) job. I thought you already had some code to do that, but thrown it away because the JIT was too slow. Was just trying to point out that such code shouldn't be thrown away completely. Did the LLVM code you had take OCaml bytecode or Ulambda/Cmm as input? So besides probably educational or research interests, what would be the practical benefit of LLVM inside ocamlopt? There would be several advantages in switching to LLVM for code generation. The general idea is that if other people work on the low-level stuff, it is less work for the OCaml implementors. - more portability : while I'm not sure LLVM is ported to more platforms than OCaml right now, OCaml's tier 1 platforms are supported by LLVM. Ocaml's tier 2 support has more architectures than LLVM though. the LLVM community will probably port its bytecode to numerous architectures in the future; I've seen some microcontroller backends added lately, but I've also seen unmaintained and broken backends removed (IA-64 for example). in contrast, maintining numerous backend in the OCaml compiler has a maintainance cost. In particular, cross-compilation would probably be easier. - more optimizations : the LLVM guys try to develop a wide range of optimization passes between LLVM IR and native code, while ocamlopt is mostly a non-optimising compiler. It's not clear however how much gain we could have, as OCaml has already optimized the most important parts, and a big part of the performance concerns are outside the LLVM area (data representation and GC). Still, the experience of GHC-LLVM has been quite positive, with noticeable improvements in some cases. On the other hand, it may be non-trivial to adapt LLVM to cope with the OCaml runtime, the GC in particuliar, and that would probably involve upstream changes to LLVM. There is some support for emitting (assembly, not JIT) code that works with OCaml 3.10, it'd probably have to be adapted for 3.12: http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/AsmPrinter/OcamlGCPrinter.cpp http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/OcamlGC.cpp http://llvm.org/releases/2.8/docs/GarbageCollection.html LLVM is nice and trendy It'd be even nicer if it was written in OCaml, whenever I write C++ code lately it feels like I could've written the same with much less code in OCaml. If someone were to develop an LLVM backend for OCaml, I think it could coexist with ocamlopt though, allowing the user to choose which backend it wants to use. (though it's a shame the GNU guys, partly due to their own mistakes, are losing an important part of the FLOSS ecosystem to Apple...), Well there could also be a GCC backend for OCaml, but I don't know how one should get started writing one (or if it would be worth it). Best regards, --Edwin ___ 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 GC [was Is OCaml fast?]
On Sun, 28 Nov 2010 15:29:08 +0100 Benedikt Meurer benedikt.meu...@googlemail.com wrote: Speaking of the OCaml GC in general, wouldn't it make sense to replace the current generational collector with a collector framework that requires less copying in the common case. Even without changing the GC algorithm, I think it would be useful if we could minimize the amount of useless work major collections do in the current GC. I profiled the binary trees with valgrind's callgrind, and it turns out that most of the time for each minor collection is spent in caml_major_collection_slice: http://www.pasteall.org/pic/show.php?id=7194 This seems to be in concordance with the smaller minor heap = more minor collections = slower program observation, since it is: smaller minor heap = more minor collections = more major slices = major slices can't collect long-lived objects = slower program (long lived objects are sweeped too many times). So more minor collections = higher cost for a major slice I think OCaml's GC should take into account how successful the last major GC was (how many words it freed), and adjust speed accordingly: if we know that the major slice will collect next to nothing there is no point in wasting time and running it. So this formula should probably be changed: p = (double) caml_allocated_words * 3.0 * (100 + caml_percent_free) / Wsize_bsize (caml_stat_heap_size) / caml_percent_free / 2.0; Probably to something that also does: p = p * major_slice_successrate where successrate is how many words the GC succeeded in collecting the last major slice (or last major collection). I'm not familiar with OCaml's GC, but it looks like it doesn't keep track of these stats during a collection, or does it? P.S.: It would be good if this internal speed percentage was tunable from the Gc module, at least by a constant factor. Best regards, --Edwin ___ 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: Is OCaml fast?
On Tue, 23 Nov 2010 18:03:10 + (UTC) Isaac Gouy igo...@yahoo.com wrote: Jon Harrop jonathandeanharrop at googlemail.com writes: Note that the regex-dna solution for Haskell tweaks its GC parameters via the -H command-line parameter: Note that there is no restriction on tuning the GC for regex-dna. Note that there is no restriction on tuning the GC for any task except binary-trees. Sounds good. Then Ocaml could still win if it performs well on the other benchmarks. Best regards, --Edwin ___ 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] Is OCaml fast?
On Mon, 22 Nov 2010 15:36:30 +0100 bluestorm bluestorm.d...@gmail.com wrote: On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann i...@gerd-stolpmann.dewrote: I think the shootout is not a good data source. There are definitely some very poor Ocaml results there, so I'd guess the shootout got recently more attention by enthusiasts of other languages, and the current Ocaml programs there are not very good. (I remember Ocaml was #1 at the shootout a few years ago, faster than C.) So maybe a good opportunity to post better Ocaml solutions there? As Sylvain noticed, some (in not most) of the OCaml poor performances in the shootout are actually not due to bad OCaml programs, but to arbitrary restrictions in the shootout rules. For example, one of the bad-performing benchmark for OCaml is the binary-tree benchmark, where it is nearly four times slower than C, but on closer inspection you discover that this is due to the arbitrary choice to forbid any change of the GC parameters. With appropriate GC parameters, the very same OCaml program is exactly as fast as C. http://shootout.alioth.debian.org/u32/performance.php?test=binarytrees « Note: these programs are being measured with *the default initial heap size* - the measurements may be very different with a larger initial heap size or GC tuning. » C version : 12.11 secs OCaml version : 47.22 secs OCaml version with GC parameters tuned (interesting alternative section) : 12.67 secs Therefore, there is nothing that can be changed to the OCaml submission for this benchmark to improve performances, except changing the default GC parameters; while this might be a good idea in general, changing it only for the sake of shootout-obsessed people is ridiculous. Isn't it possible for the GC to realise its doing too many collections and increase the minor heap size on its own? Or isn't it possible to determine at compile time an approximation for a good heap size, and use that? Best regards, --Edwin ___ 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] Is OCaml fast?
On Mon, 22 Nov 2010 17:46:49 +0100 Fabrice Le Fessant fabr...@lefessant.net wrote: 2010/11/22 Török Edwin edwinto...@gmail.com: Isn't it possible for the GC to realise its doing too many collections and increase the minor heap size on its own? Indeed, it could notice that a lot of data is being moved to the major heap, and double its size in consequence, until a maximum limit is reached. I did some benchmarks on 2 CPUs, and here are the wall clock times for GC minor heap size: minorheap, phenomII,,, core2,,,cycle diff % , time,, cycles,time,, cycles, 32, 17.76,17.74,56.8, 48.60,48.86,58.48,2.96 64, 16.81,16.80,53.78,44.79,44.79,53.75,-0.06 128, 15.41,15.38,49.26,41.38,40.76,49.28,0.04 256, 14.39,14.35,45.98,39.75,38.98,47.24,2.74 512, 12.97,13.15,41.79,35.75,35.59,42.8,2.42 1024, 12.89,12.94,41.33,33.57,33.13,40.02,-3.17 2048, 11.05,11.09,35.42,29.26,29.12,35.03,-1.1 4096, 9.79, 9.81,31.36,26.21,25.96,31.3,-0.19 8192, 8.71, 8.85,28.1, 23.36,23.34,28.02,-0.28 16384,7.89, 7.86,25.2, 21.41,21.54,25.77,2.26 32768,7.55, 7.55,24.16,20.74,20.88,24.97,3.35 (minorheap is in KWords, time is in seconds, cycles is divided by 10^9) Increasing minor heap beyond that yielded no improvement (number of minor heap collections stayed the same). phenomII has 64 Kb L1 data cache, 512Kb L2 cache, 6144Kb L3 cache (shared), runs at 3.2Ghz. That would be 516k words if only 1 core used. core2 has 32 Kb L1 data cache, 4MB L2 cache, runs at 1.2Ghz. That would be 840k words if only 1 core used. Both used exact same binaries on 64-bit Linux, ocaml 3.11.2. Despite the difference in CPUs and heap sizes the number of CPU cycles spent for a given size of the minor heap is about the same (within 3% difference). Not sure what the max should be for the minor heap increase, but based on this benchmark increasing size of minor heap never slows down the program. Even when size of minor heap exceeds what fits in the cache. I guess there is another microbenchmark that can show the opposite though. Is there some real world benchmark for OCaml's GC that can be used to get some better values for minor heap size based on CPU's L2/L3 size (as suggested in the 'Optimizing garbage collection' thread)? The problem is that it is the kind of things that are application dependent, Yes, maybe optimal size of minor heap doesn't depend on CPU's cache size but on the application, in which case a heuristic for increasing/decreasing the heap size may be better? and should be put in the program itself (the program would have a trigger on each minor heap collection, and, depending on the moved bytes, would increase the size of the minor heap). The problem is that the Shootout does not allow that, so the winner is the language whose runtime allocates the most memory at the beginnning... If tuning minor heap can double performance of the program, then the GC should have some heuristics to tune it automatically. Sure applications which are not happy with that tuning should tune it themselves. Best regards, --Edwin ___ 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] Causes for segfaults
On Mon, 15 Nov 2010 18:38:18 + Jamie Brandon ja...@scattered-thoughts.net wrote: Excessive recursion of a function does raise an exception, on most platforms, doesn't it? [r...@senldogo0183 texsearch-development2]# uname -a Linux senldogo0183 2.6.18-53.el5 #1 SMP Wed Oct 10 16:34:19 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux [r...@senldogo0183 texsearch-development2]# ocaml -version The Objective Caml toplevel, version 3.12.0 [r...@senldogo0183 texsearch-development2]# cat segfault.ml let rec ints n = n :: ints (n+1) let _ = ints 0 [r...@senldogo0183 texsearch-development2]# ocamlopt segfault.ml [r...@senldogo0183 texsearch-development2]# ./a.out Segmentation fault I get a proper exception: Fatal error: exception Stack_overflow Linux debian 2.6.36-phenom #107 SMP PREEMPT Sat Oct 23 10:30:01 EEST 2010 x86_64 GNU/Linux Although you have to be careful with recursion and calls to C code, calling the C code may be the one overflowing the stack, and the ocaml runtime doesn't generate stack overflow exception for that (only for OCaml code). You will probably need the patch from http://caml.inria.fr/mantis/view.php?id=5064 for that. Best regards, --Edwin ___ 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] scalable web apps
On Sun, 25 Jul 2010 06:52:46 -0700 (PDT) Dario Teixeira darioteixe...@yahoo.com wrote: The only circumstance where I would be cautious on relying solely on a naked Ocsigen is if you are also required to serve plenty of static content (images, etc). Even though Ocsigen includes an extension for serving static pages, for hysterical reasons no Unix supports non-blocking mode for regular files, which of course causes problems for Lwt-apps (see the Lwt manual for more information on this). I thought ocaml's threads are meant to solve the I/O problem. Doesn't it use native pthreads for each OCaml thread, and prior to performing I/O it releases the mutex allowing other threads to run? Of course you'd still have to wait for the I/O to complete to serve the file to one particular user, but in the meantime you could serve some other (already cached) file to another user, generate some dynamic content, etc. Lwt's Lwt_preemptive seems to allow one to use 'preemptive threads' (which I assume are just usual OCaml threads). So would it be possible to put the file I/O on Lwt_preemptive.detach threads? Has anyone tried to measure the performance of doing that? Best regards, --Edwin ___ 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] scalable web apps
On Mon, 26 Jul 2010 09:59:01 +0200 Jérémie Dimino jere...@dimino.org wrote: On Mon, Jul 26, 2010 at 10:29:04AM +0300, Török Edwin wrote: Lwt's Lwt_preemptive seems to allow one to use 'preemptive threads' (which I assume are just usual OCaml threads). So would it be possible to put the file I/O on Lwt_preemptive.detach threads? Yes. Has anyone tried to measure the performance of doing that? Yes, i tried it some time ago with two small C programs which were just reading a file on the disk. One doing read operations in a simple loop, and one launching a thread for each read operation (or reusing the same thread). The threaded version was about 100 times slower than the non-threaded one. BTW it is planed to add some kind of asynchronous file I/O support in Lwt by using mmap and mincore. How about using linux's AIO and eventfd? Manpage of eventfd says: When used in the kernel, an eventfd file descriptor can provide a kernel-userspace bridge allowing, for example, functionalities like KAIO (kernel AIO) to signal to a file descriptor that some operation is complete. A key point about an eventfd file descriptor is that it can be monitored just like any other file descriptor using select(2), poll(2), or epoll(7). This means that an application can simultaneously monitor the readiness of tra‐ ditional files and the readiness of other kernel mechanisms that support the eventfd interface. And looks like libaio-ocaml has support for eventfd in AIO: val fd : context - Unix.file_descr (** return eventfd associated with the context *) I think there could be a Lwt_unix.read_aio that is just like Lwt_unix.read, except it checks the eventfd descriptor for being readable instead of the original fd, and use Aio.read instead of usual read, etc. Best regards, --Edwin ___ 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] scalable web apps
On Mon, 26 Jul 2010 12:57:55 -0700 Jake Donham j...@donham.org wrote: On Mon, Jul 26, 2010 at 12:59 AM, Jérémie Dimino jere...@dimino.org wrote: Yes, i tried it some time ago with two small C programs which were just reading a file on the disk. One doing read operations in a simple loop, and one launching a thread for each read operation (or reusing the same thread). The threaded version was about 100 times slower than the non-threaded one. This is perhaps off-topic for the list, but what is the reason for this? I can imagine that launching a thread might be heavy, but is the context-switch overhead for threads so bad? BTW it is planed to add some kind of asynchronous file I/O support in Lwt by using mmap and mincore. How would this work? Is it possible to be notified when the page comes into core (mincore appears to support only polling)? With AIO I think so, without it I don't know how. Is it possible to request a page without blocking (by reading from it)? Just curious. Jake ___ 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] Distinguish between osx and linux programmatically
On Thu, 8 Jul 2010 17:22:15 + David Allsopp dra-n...@metastack.com wrote: Oliver Bandel wrote: On Thu, Jul 08, 2010 at 06:01:24PM +0100, Richard Jones wrote: On Thu, Jul 08, 2010 at 10:42:40AM -0500, Romain Beauxis wrote: Le jeudi 8 juillet 2010 06:44:34, Richard Jones a écrit : Stdlib could bind the uname(2) syscall, but it's legendary in its complexity. Seems more likely to cause problems than just calling out to the external program. I fail to see the complexity.. Where is it ? Actually *I* misunderstood the link I posted (http://www.kernel.org/doc/man-pages/online/pages/man2/uname.2.html#NO TES) thinking it meant that the string fields in the structure could have variable width. Reading it again, they don't. Nevertheless I still think this is not a useful addition to stdlib, but for different reasons: (1) You'd have to emulate it on non-Unix platforms, but it's unclear what you'd emulate it with. Windows has a completely different and much richer concept of OS version. This sort of version probing complexity doesn't belong in the core library, but in an external OS version library where detection rules can be frequently updated. [...] $ uname -a If it's not Unix, what will uname(2) or uname(1) give you? What will be reported on Windows with MinGW C:\Users\DRAuname -a windows32 Tenor 2.6.1 7600 i686-pc Intel unknown MinGW (using GnuWin32 which is a MinGW build of the Unix tools) or Cygwin? d...@tenor ~ $ uname -a CYGWIN_NT-6.1-WOW64 Tenor 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin But of course in both instances that requires uname.exe to be installed which it won't be on most normal end-user systems. OCaml already calls uname(), and has a configure check for its presence: ./configure: echo uname() found. ./otherlibs/unix/gethostname.c: uname(un); I think it would only be a matter of using uname() for something more than just the hostname. Of course finding out the OS version from uname is more complicated (Linux has the kernel's version, and there is no way to find out the distribution, etc.), but a portable program shouldn't care much about the exact OS version, as long as it knows the OS type. Best regards, --Edwin ___ 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] Unix.send blocks
On 06/16/2010 10:32 AM, Paul Steckler wrote: I've written a wee Web server in OCaml that's compiled using the ocamlopt from the Fedora MinGW distribution of ocaml. I'm running the server in Windows 7. Sometimes after receiving several requests, the Unix.send call that sends a response back to a Web client just blocks. Why is a blocking send() a problem? Isn't your application multithreaded? The send buffer is pretty large (64k), and the data to be sent is always much less than that. From the manpage of send: If space is not available at the sending socket to hold the message to be transmitted, and the socket file descriptor does not have O_NONBLOCK set, send() shall block until space is available. I think this occurs if the client has a slow/high latency connection, and it doesn't acknowledge the TCP packets in time. The packets you send are queued up in the kernel's TCP stack until they are acknowledged or time out. There is only a limited amount of data that can be buffered up like this per connection, when that is hit send() blocks. You could set the socket to nonblocking mode (and check with 'select' whether you can send), but according to the manual that doesn't work on the native windows port of OCaml. Best regards, --Edwin ___ 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.12.0+beta1
On 06/16/2010 04:07 PM, Damien Doligez wrote: Dear OCaml users, We have the pleasure of celebrating Bloomsday by announcing the release of OCaml version 3.12.0+beta1. This is a beta release, available as source only and intended for power users to test new features and report bugs (if any). I have run the included OCaml testsuite, but I must have done something wrong since I got some compile failures (unbound modules, and some missing symbols when linking thread-related tests). make report output: Summary: 278 test(s) passed 8 test(s) failed 24 compilation error(s) 0 compilation warning(s) My system is a Debian Linux x86_64. What I've done is: ./configure -prefix ~/compilers/o312 make world.opt make install Then put $HOME/compilers/o312/bin first in PATH. Then I've simply run a 'make all' in testsuite/ (under ulimit -v 1024000 -d 1024000 -t 3600). Note that I also have ocaml 3.11.2 installed. The failures are below, is this something I'm doing wrong, or should I open a bugreport? ... testing 't01.ml'Fatal error: cannot load shared library dllcamlstr Reason: dllcamlstr.so: cannot open shared object file: No such file or directory ... testing 'Exemples.ml.reference':Files Exemples.ml.reference and Exemples.ml.result differ = failed ... testing 'Tests.ml.reference':Files Tests.ml.reference and Tests.ml.result differ = failed ... testing 'poly.ml.principal.reference':Files poly.ml.principal.reference and poly.ml.principal.result differ = failed ... testing 'poly.ml.reference':Files poly.ml.reference and poly.ml.result differ = failed ... testing 'private.ml.reference':Files private.ml.reference and private.ml.result differ = failed The link failures in the testsuite look like this: /home/edwin/compilers/o312/lib/ocaml/threads/threads.a(thread.o): In function `camlThread__fun_1101': (.text+0x4b): undefined reference to `caml_thread_uncaught_exception' /home/edwin/compilers/o312/lib/ocaml/threads/threads.a(thread.o): In function `camlThread__fun_1086': (.text+0x8a): undefined reference to `caml_wait_signal' The unbound module: ... testing 'tbuffer.ml': ocamlcFile tbuffer.ml, line 3, characters 0-12: Error: Unbound module Testing Best regards, --Edwin ___ 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] [ANNOUNCE] llpp
On 06/12/2010 09:36 PM, malc wrote:
Hello,
Long story cut short: the PDF viewers that are available for my machine
leave a lot to be desired for my usage pattern, so i had to write yet
another, the code is at:
http://repo.or.cz/w/llpp.git
http://repo.or.cz/w/llpp.git/blob_plain/master:/BUILDING explains how to
build it.
Appears to be working fine so far, and much faster than okular.
Two minor issues:
1. The mupdf from sumatrapdf installs fitz.h and mupdf.h directly into
/usr/local/include, and not under fitz/, or mupdf/, so llpp failed to
compile. I fixed by copying the headers to where llpp expected them to be.
2. It segfaults if the file is not found, fix below:
diff --git a/link.c b/link.c
index 7ca7684..7dab233 100644
--- a/link.c
+++ b/link.c
@@ -177,7 +177,8 @@ static void __attribute__ ((format (printf, 2, 3)))
static void die (fz_error error)
{
fz_catch (error, aborting);
-pdf_closexref (state.xref);
+if (state.xref)
+ pdf_closexref (state.xref);
exit (1);
}
Best regards,
--Edwin
___
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] build/fastworld issues
On 2010-06-10 23:21, Nicolas Pouillard wrote: On Fri, 04 Jun 2010 10:56:51 +0300, Török Edwin edwinto...@gmail.com wrote: Hi, I have successfully built 3.12.0+dev25 with 'make world.opt', but I get an error if I try 'build/fastworld.sh'. Both 'make world.opt' and 'build/fastworld.sh' work fine on ocaml 3.11.2. Here is the error: + ./ocamlopt.opt -nostdlib -c -g -warn-error A -I otherlibs/dynlink/nat -I stdlib -o otherlibs/dynlink/nat/dynlink.cmx otherlibs/dynlink/nat/dynlink.ml File otherlibs/dynlink/nat/dynlink.ml, line 43, characters 0-15: Error: Unbound module Cmx_format Command exited with code 2. Compilation unsuccessful after building 1621 targets (678 cached) in 00:00:18. This happens on Debian unstable, x86-64. Should I open a bugreport, or is reporting to this list about problems with trunk enough? This issue is fixed in the 3.12 branch. Thanks, switching to 3.12 branch worked. Not being familiar with OCaml development process I thought that 3.12 will be released from trunk, I didn't know 3.12 branch existed already. Best regards, --Edwin ___ 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] Escaped string in sexplib
On 06/08/2010 09:52 PM, Hugo Ferreira wrote: Hello, Markus Mottl wrote: On Tue, Jun 8, 2010 at 11:44, Hugo Ferreira h...@inescporto.pt wrote: I am trying to us the Sexplib library to process data. However I am having some trouble with strings. Specifically I need to save and restore strings to a file so that the escaping done during saving is undone when data is read back in. How can I do this? Appreciate any pointers. The I/O and parsing routines in the S-expression library should take care of escaped strings just fine. My apologies but I did not explain myself correctly. The problem here is that I am trying to automate the conversion to string of the data structure read from the s-expressions. I have the following: let string_of_experiment_data data = let data = sexp_of_experiment_data data in Sexplib.Sexp.to_string_hum data The problem here is that the to_string_hum escapes certain characters, but I need to have the strings not escaped. So my question is: is their any way I can tell sexplib to output a string but not escape it? Otherwise I will have to hand encode this stuff 8-( Btw., the escaping conventions are absolutely identical to the ones used by OCaml. I am aware of this as it is indicated in your documentation and the ocaml tutorial site. I also searched for a means to unescape the result from to_string_hum, which would also work. However I cannot find a String.unescape. This issue has already been pointed out. A possible solution would be to use the old. Token.eval_string and I cannot seem to use the equivalent of the new camlp4. The equivalent: open Camlp4.PreCast open Syntax let eval_string s = Camlp4.Struct.Token.Eval.string ~strict:() s does not compile (Error: Unbound module Camlp4.PreCast). It compiles for me if I add -I +camlp4: ocamlc -I +camlp4 -c x.ml or: ocamlfind ocamlc -package camlp4.lib -c x.ml It also links if you add -linkpkg. Best regards, --Edwin ___ 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] Converting variants with only constant constructors to integers
Hi, What is the recommended way to convert a variant that has only constant constructors to an integer? (an integer that is unique for each constant constructor, preferably sequential in the order in which they are declared). I found the following two possibilities, but I am not sure if these are guaranteed to return the same results for future versions of OCaml or not: let int_of_constant_variant a : int = Hashtbl.hash a;; let int_of_constant_variant a : int = let r = Obj.repr a in assert (Obj.is_int r); (Obj.magic r : int);; for 'type t = A | C | B', both of these functions return 0,1, and 2 for A,C, and B respectively. Best regards, --Edwin ___ 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] Converting variants with only constant constructors to integers
On 06/07/2010 09:31 PM, Török Edwin wrote: On 06/07/2010 09:23 PM, Wojciech Meyer wrote: Török Edwin edwinto...@gmail.com writes: What is the recommended way to convert a variant that has only constant constructors to an integer? (an integer that is unique for each constant constructor, preferably sequential in the order in which they are declared). In the first play you'd need to tell us, why would you need this Yes, I probably should have started with that. I have some flags like: type myflags = Property1 | Property2 | Property3;; I have something similar code in C, as an enum. I need to convert to convert OCaml lists of flags to an integer, that will ultimately be passed to a C function. So [Property1; Property3] needs to become (1 Property1) | (1 Property3). I want to do this conversion in OCaml code. Important is that Property1 from OCaml gets the same value as Property1 in the C enum. , and then maybe there are other solutions to your problem. Most likely Marshal module from stdlib, will full-fill your requirements. If I only had OCaml code to deal with yes, but see above. I can imagine you could use an association list, function with pattern matching I don't have too many flags, so I could write a simple pattern matching function to convert to int (even manually). I just thought there is a way to do this easily, and more general than that. , code generation tool (based on CamlP4), etc. The later would be needed if you have varied data structure, that change frequently or it is too big to maintain it with just pattern matching. I found the following two possibilities, but I am not sure if these are guaranteed to return the same results for future versions of OCaml or not: let int_of_constant_variant a : int = Hashtbl.hash a;; let int_of_constant_variant a : int = let r = Obj.repr a in assert (Obj.is_int r); (Obj.magic r : int);; There is no guarantee of these kind of unsafe casts at all (means using Obj.magic). Especially Obj.magic should not be used in marshaling, but most common patter is for type system tricks. How about the hash value? I guess no guarantees about that either. Best regards, --Edwin ___ 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] Converting variants with only constant constructors to integers
On 06/07/2010 09:48 PM, David Allsopp wrote: Török Edwin wrote: What is the recommended way to convert a variant that has only constant constructors to an integer? (an integer that is unique for each constant constructor, preferably sequential in the order in which they are declared). type foo = A | B;; external int_of_foo : foo - int = %identity;; Which is another way of saying Obj.magic - but %identity is an OCaml primitive, where Obj.magic is part of a restricted module so there is a small semantic difference in terms of future support. The internal representation of variants won't change until at least OCaml 4.0.0 - there're simply far too many C bindings out there! foo_of_int obviously can't be done quite so trivially written although having checked that the int represents a valid constructor you can then use %identity in the same way. Thanks, that %identity looks exactly what I wanted. I don't need a foo_of_int right now. On 06/07/2010 09:45 PM, bluestorm wrote: 2010/6/7 W Dan Meyer wojciech.me...@googlemail.com mailto:wojciech.me...@googlemail.com I can imagine you could use an association list, function with pattern matching, code generation tool (based on CamlP4), etc. I wrote a type-conv ( http://www.ocaml.info/home/ocaml_sources.html#type-conv ) generator for just that a few years ago : http://bluestorm.info/camlp4/ty_enum_to_int.ml.html Example use : type test = | A | B | C | D of bool with to_int Generated functions : let test_to_int = function | A - 0 | B - 1 | C - 2 | D _ - 3 let test_of_int = function | 0 - A | 1 - B | 2 - C | 3 - failwith can't convert to a constructor with parameters: D | _ - invalid_argument test_of_int If I'll need a foo_of_int this sounds like a good solution, thanks. Best regards, --Edwin ___ 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] build/fastworld issues
Hi, I have successfully built 3.12.0+dev25 with 'make world.opt', but I get an error if I try 'build/fastworld.sh'. Both 'make world.opt' and 'build/fastworld.sh' work fine on ocaml 3.11.2. Here is the error: + ./ocamlopt.opt -nostdlib -c -g -warn-error A -I otherlibs/dynlink/nat -I stdlib -o otherlibs/dynlink/nat/dynlink.cmx otherlibs/dynlink/nat/dynlink.ml File otherlibs/dynlink/nat/dynlink.ml, line 43, characters 0-15: Error: Unbound module Cmx_format Command exited with code 2. Compilation unsuccessful after building 1621 targets (678 cached) in 00:00:18. This happens on Debian unstable, x86-64. Should I open a bugreport, or is reporting to this list about problems with trunk enough? Best regards, --Edwin ___ 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] Multi-threaded programs using MinGW x-compiler
On 2010-05-24 04:39, Paul Steckler wrote: Has anyone gotten an OCaml multithreaded program to build for Win32 native threads using the MinGW ocaml cross-compiler? I'm not a windows user, but I tried with Debian's mingw32-ocaml package and wine: it seems to work. I don't know if it uses native threads or not, but it does import CreateThread. Here is what I did: $ cat x.ml EOF let f_proc1 () = for i=0 to 10 do Printf.printf (%d) i; flush stdout done; print_newline() ;; let t1 = Thread.create f_proc1 () ;; Thread.join t1 ;; EOF $ i586-mingw32msvc-ocamlopt -thread unix.cmxa threads.cmxa x.ml $ WINEDEBUG=-all wine camlprog.exe (0)(1)(2)(3)(4)(5)(6)(7)(8)(9)(10) $ i586-mingw32msvc-nm camlprog.exe |grep Thread 0042da60 T _createthr...@24 0042daa0 T _getcurrentthr...@0 0044f3b4 I __imp__createthr...@24 0044f3e0 I __imp__getcurrentthr...@0 0042ec9c D _camlThread 0042ef98 D _camlThreadUnix Best regards, --Edwin ___ 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 defunctorization and other optimizations
On 05/20/2010 02:40 PM, Julien Signoles wrote: Hello, 2010/5/20 Török Edwin edwinto...@gmail.com mailto:edwinto...@gmail.com On 05/20/2010 11:41 AM, Julien Signoles wrote: I think that'll have to be someone else than me, as I consider myself just a beginner in OCaml. However if you think that implementing AST transforms would be possible for a beginner (in OCaml, I do have experience with compilers), I'm willing to give it a try. I wrote ocamldefun during my master project where I done both the theory and the implementation of this tool: I was a beginner both in ocaml and in functional programming since I only wrote a mini-compiler in ocaml during my studies without any lecture on functional programming. That sounds encouraging. But ok: there were ocaml experts in my research team which provide me some wonderful helps :-). I think that if there is a defunctorizer written it should live in the OCaml distribution itself (maybe in contrib/). Ocaml is not Coq: there is no such contrib/ directory ;-). OK, I haven't payed much attention to the structure of the OCaml package, I just assumed there was such a directory. As far as I know, the Ocaml development team does not accept so much external contributions (for many good reasons). OK, then it'll have to be an external tool (if I decide to write it after all). I certainly don't intend to write an external tool that uses OCaml internal modules. That is what ocamldefun actually does. Yes, but I was thinking of something that is using an exported and documented interface (like camlp4). I think it would be easier to keep up with new OCaml versions that way. Best regards, --Edwin ___ 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] OCaml defunctorization and other optimizations
Hi, I've seen in several places recommendations to use 'ocamldefun' to speed up OCaml programs that use functors heavily [*]. I was able to find the sources via the wayback machine. Unsurprisingly it doesn't build with OCaml 3.11.2 (it wants OCaml 3.06). Is there a more up to date variant of ocamldefun? Would it be possible to port it to 3.11.2? Is it possible to implement ocamldefun-like functionality via Camlp4's AST filters? Also is it possible to implement function specialization (monomorphization?) using an AST filter? The example from the OCaml tutorial is not optimized by http://www.ocaml-tutorial.org/performance_and_profiling. Or is it possible to get access to the OCaml compiler's IL representation and make optimizations on that? [*] For example when extracting ML programs from Coq using OCaml's native 'int' type I get code like this (which is not inlined/optimized at all by OCaml): module Z_as_Int = struct let _2 = 2 let mult = ( * ) ... end module F = functor (I:Int) - struct (** val mul2 : I.int - I.int **) let mul2 n = I.mult I._2 n end module F2 = F(Z_as_Int) Best regards, --Edwin ___ 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
