[Caml-list] Alignment of data
Goswin von Brederlow goswin-...@web.de wrote: You need to write a new function CAMLextern value caml_alloc_double_array (mlsize_t), or similar that ensures alignment on 8 byte for double even for 32bit systems. You should also check the CAMLextern value caml_copy_double (double); that it does the same. If you decide to go this route, which this message neither endorses not condemns, you also need to A1/ allocate the doubles directly in the major heap, and A2/ deactivate compactions or B/ modify the garbage-collector. Pascal ___ 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
On Sep 24, 2009, at 5:47 PM, Philippe Wang wrote: Is the copy operation parallelized? Nope. When the world is stopped for the collection, everything is done sequentially until the world is resumed. I don't think it's relevant to parallelize the copy operation (hell to implementdebug, then I don't think that performance would be very interesting because we would probably need a write mutex on the destination heap) Well, you could start copying to the bottom of the next heap with one thread going up and to the top of it with another going down. Assume optimistically that the two threads will not reach the same cacheline at the end of the copies, and you don't need any synchronisation at all between them, except joining at the end. After checking, if they have reached the same cacheline, you need to reallocate the destination heap anyway. You still get a single unfragmented free block as a result. Even better: stop the world just before there remains less that one cacheline of free space and you don't need to check if the two threads have met. You still need to reallocate the destination heap sometimes though. Oh, and I meant to say, but everyone else was faster than me: well done! Pascal ___ 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 don't you use batteries?
Edgar Friendly thelema...@gmail.com wrote: Erik de Castro Lopo wrote: Mike Lin wrote: Ditto, Due to the sparsity of OCaml's standard library, many long term users probably have their own library to do all sorts of little things they need, and substantial amounts of code written around it. :-( Double ditto. I have quite a large amount of stuff sitting on top of extlib/str/unix. Erik Would you consider donating any of it to batteries? 17) I don't want to use any library that will accept code from people like me. Grou^H^H^H^H Pascal___ 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: Physical counterpart to Pervasives.compare?
Christophe Raffalli christophe.raffa...@univ-savoie.fr wrote: Or, if all major GCs are compacting and the minor heap is at a higher adress than the major heap, then OCaml's could also preserve the adress order between GC ... I do not think that the current minor GC algorithm does any effort to copy the live blocks from the minor heap in order (i.e. to copy first the blocks with the lower addresses). It copies them as it finds them, recursively. Two blocks from the minor heap may still see the order in which they are in memory change when they are both copied to the major heap. For this reason, I do not think that the above trick would work. Pascal ___ 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] Physical counterpart to Pervasives.compare?
Pascal Cuoq a écrit :
Elnatan Reisner wrote:
Is there something that can complete this analogy:
(=) is to (==) as Pervasives.compare is to ___?
The simple solution is to number at creation the objects that you
want to
physically compare, using an additional field.
Since people are still participating in this topic,
I have a remark. It is more a what not to do kind of
remark, but after replying last time, I remembered
that the current algorithm used by OCaml's GC
for compaction does not change the order of blocks
in memory (byterun/compact.c). Therefore, with the
current version, if you make sure in some way
that the values that you want to compare
are allocated directly in the major heap
(there are a couple of ways to do that),
you can theoretically compare their addresses
as unsigned longs: their order will not change
during execution.
But you should still do the comparison
with a unique C function written for this purpose.
If you tried to use a convert address to int function,
you would have a race condition between the conversion
of each address and garbage collection.
This is all in very poor taste, even more so than
the usual discussions about == on this list.
Do I get some kind of prize for breaking the record?
Pascal
__
PS: I wrote a convert address to int function for
another purpose once. In order to increase my chances
for the prize, I will provide it here. Someone might be
interested in it. Perhaps someone who maintains a small
library for computing the size of an ML value...
external address_of_value: 'a - int = address_of_value
value address_of_value(value v)
{
return (Val_long(((unsigned long)v)/sizeof(long)));
}
___
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] native GTK+ on Mac OS X
On Mar 30, 2009, at 7:41 AM, Grünewald Michaël wrote: Did you have Gtk+ working natively in OSX? Joel Reymont joe...@gmail.com wrote: I do but I built from source after downloading the GTK+/OSX frameworks and using ./configure --with-quartz I also had to place the following two (identical) files in /opt/local/ lib/pkgconfig since my pkg-config comes from MacPorts Alternately, I have found that I could use MacPorts for everything GTK+ and still get the Quartz back-end if I follow the instructions for compiling a native Mac OS X version of Inkscape: http://www.inkscape.org/wiki/index.php/CompilingMacOsX For distributing binaries, I build my quartz variant of MacPorts as a subdirectory of the installation path that I wish to use (/usr/local/Frama-C/lib/macports), and include in the distributed archive those libraries that are necessary for running Frama-C. See the contents of one of the Mac OS X distributions for details: http://frama-c.cea.fr/download.html This unfortunately means that the binaries can not be installed anywhere else. Gimp.app (http://gimp-app.sourceforge.net/) allows to move the application around by using a shell script to change, at each launch, the paths in all the configuration files that have them hard-coded. But some of the libraries that Frama-C depends on seem to have binaries files with hard-coded paths, so I didn't succeed in doing the same thing. Tangentially, I would be interested in any improvement suggestions from people more knowledgeable that me on the subject of gtk-quartz, displaying unicode with pango on Mac OS X, and their interactions with OCaml. Pascal ___ 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] bootstrapping OCaml after changing the runtime
Hi all, there was a thread earlier this summer on the topic of the bootstrap: http://groups.google.com/group/fa.caml/browse_thread/thread/a39e6699f0c5043d I should add a tidbit of information that took me a while to figure out to the information there. The information from the thread is: look at the comment 'Hard bootstrap how-to' in the toplevel Makefile of the OCaml [CVS] distribution The additional tidbit is: if you are trying to add a new primitive, try splitting the patch in two parts, the part that contains the C primitive (the CAMLprim ... in a .c file) and the part that makes it visible from caml (the external ... in an .ml file). Apply the first patch only first, bootstrap, apply the second one and bootstrap again. I did not see this information explicitly documented anywhere, but it was implicitly contained in the following web page: http://www.pps.jussieu.fr/~henry/marshal/index.en.html Pascal ___ 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
