On 18-11-2010, Goswin von Brederlow goswin-...@web.de wrote:
Hi,
I'm looking for stubs for
ssize_t sendmsg(int sockfd, const struct msghdr *msg, int flags);
ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags);
Specifically I need those to send (among normal messages)
On 18-11-2010, Thomas Gazagnaire thomas.gazagna...@inria.fr wrote:
Hi all,
I've got a source tree with the following patterns :
A/a.ml (defines 'let x = 1')
B/a.ml (use A.x and defines 'let y = 2')
B/b.ml
B/b.mlpack (contains 'A B')
C/a.ml (use A.x)
C/b.ml (use B.A.y)
C/c.mlpack
On Thu, 18 Nov 2010 00:08:19 +0100, Christophe Raffalli wrote:
And OCaml on GPU ? We just tested a recent GPU card with 480
processors at 900Mhz ... this is qui impressive ... and supported by
matlab via cuda-lapack (http://www.culatools.com/) ... I imagine we
could at least use cuda-lapack
Benedikt Meurer wrote, On 11/19/2010 06:29 AM:
This is indeed very interesting. I haven't thought of the native top-level. I
haven't done any measurements yet, but from my experience with ocamlopt, I
know that the optimizing native compiler is somewhat slower than the
byte-code compiler. I
Hi,
I'm looking for stubs for
ssize_t sendmsg(int sockfd, const struct msghdr *msg, int flags);
ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags);
Specifically I need those to send (among normal messages) an
Unix.file_descr over a Unix Domain Socket.
Does
On Thu, Nov 18, 2010 at 08:43:28AM +0100, ri...@happyleptic.org wrote:
Each time I need more debug information for the ocaml runtime itself
(which hopefully is not often) I recompile Ocaml adding various -g
and -O0 here and there in some makefiles.
See the description of how to build ocamlrund
There seem to be solutions in theory. I think a colleague had pointed out
one of the papers below, so there is indeed something like a lock-free
garbage collector. Then, why do we worry about much synchronization
overhead? I don't quite understand.
Maurice
Hello everybody,
OCamlJit 2.0 is a new Just-In-Time engine for Objective Caml 3.12.0 on desktop
processors (x86/x86-64). It translates the OCaml byte-code used by the
interpreter (ocamlrun and ocaml) to x86/x86-64 native code on-demand and runs
the generated native code instead of interpreting
On 11/18/2010 09:51 AM, Eray Ozkural wrote:
A program I wrote constructs a lot of small lists, and strings and
discards them. It's a search algorithm. I profiled this code and saw
that garbage collection takes significant time.
In C++, we can write custom allocators to optimize the data
On 18 Nov 2010, at 07:43, ri...@happyleptic.org wrote:
Each time I need more debug information for the ocaml runtime itself
(which hopefully is not often) I recompile Ocaml adding various -g
and -O0 here and there in some makefiles.
But I've noticed there are some special targets and rules,
Thanks a lot for the suggestions Michael. Much appreciated.
Best,
--
Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct
___
Christophe TROESTLER christophe.troestler+oc...@umh.ac.be writes:
On Thu, 18 Nov 2010 00:08:19 +0100, Christophe Raffalli wrote:
And OCaml on GPU ? We just tested a recent GPU card with 480
processors at 900Mhz ... this is qui impressive ... and supported by
matlab via cuda-lapack
Sylvain Le Gall sylv...@le-gall.net writes:
On 18-11-2010, Goswin von Brederlow goswin-...@web.de wrote:
Hi,
I'm looking for stubs for
ssize_t sendmsg(int sockfd, const struct msghdr *msg, int flags);
ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags);
Specifically
Dave Scott dave.sc...@eu.citrix.com writes:
Hi,
I'm looking for stubs for
ssize_t sendmsg(int sockfd, const struct msghdr *msg, int flags);
ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags);
Specifically I need those to send (among normal messages) an
Hello,
On 19-11-2010, Goswin von Brederlow goswin-...@web.de wrote:
Sylvain Le Gall sylv...@le-gall.net writes:
On 18-11-2010, Goswin von Brederlow goswin-...@web.de wrote:
Hi,
I'm looking for stubs for
ssize_t sendmsg(int sockfd, const struct msghdr *msg, int flags);
Hello,
2010/11/18 Ashish Agarwal agarwal1...@gmail.com:
Rapid prototyping for me often involves a couple of lines of code that read
in a very large file and do something with it. I have to keep compiling
these small programs to native code because the performance of the toplevel
is too slow.
On Fri, Nov 19, 2010 at 1:09 PM, David MENTRE dmen...@linux-france.org wrote:
Hello,
2010/11/18 Ashish Agarwal agarwal1...@gmail.com:
Rapid prototyping for me often involves a couple of lines of code that read
in a very large file and do something with it. I have to keep compiling
these
On Fri, Nov 19, 2010 at 1:24 PM, Hezekiah M. Carty hca...@atmos.umd.eduwrote:
ocamlscript is certainly a wonderful tool, for prototyping and
otherwise. It unfortunately doesn't help specifically with the load
a large file and do something with it case.
Right.
Also, I should mention that a
Sylvain Le Gall sylv...@le-gall.net writes:
Hello,
On 19-11-2010, Goswin von Brederlow goswin-...@web.de wrote:
Sylvain Le Gall sylv...@le-gall.net writes:
On 18-11-2010, Goswin von Brederlow goswin-...@web.de wrote:
Hi,
I'm looking for stubs for
ssize_t sendmsg(int sockfd,
On Nov 19, 2010, at 19:30 , Ashish Agarwal wrote:
On Fri, Nov 19, 2010 at 1:24 PM, Hezekiah M. Carty hca...@atmos.umd.edu
wrote:
ocamlscript is certainly a wonderful tool, for prototyping and
otherwise. It unfortunately doesn't help specifically with the load
a large file and do
On Nov 16, 2010, at 6:52 AM, Benedikt Meurer wrote:
Hello everybody,
Hi,
OCamlJit 2.0 is a new Just-In-Time engine for Objective Caml 3.12.0 on
desktop processors (x86/x86-64). It translates the OCaml byte-code used by
the interpreter (ocamlrun and ocaml) to x86/x86-64 native code
On Nov 19, 2010, at 19:43 , Yoann Padioleau wrote:
OCamlJit 2.0 was specifically designed for desktop processors and is not
really portable to anything else in its current shape, because the target
audience are people using the interactive top-level and the byte-code
interpreter for rapid
On Nov 19, 2010, at 11:02 , Fabrice Le Fessant wrote:
Benedikt Meurer wrote, On 11/19/2010 06:29 AM:
This is indeed very interesting. I haven't thought of the native top-level.
I haven't done any measurements yet, but from my experience with ocamlopt, I
know that the optimizing native
Hi,
What would be really nice is to make a JIT for a language that really
need one, like PHP! There are lots of companies out there (Yahoo,
Facebook, wikimedia) that spend hundreds of millions of dollars on
machines that run PHP bytecode interpreters implemented by people who
are not Xavier
On Nov 19, 2010, at 11:46 AM, Dario Teixeira wrote:
Hi,
What would be really nice is to make a JIT for a language that really
need one, like PHP! There are lots of companies out there (Yahoo,
Facebook, wikimedia) that spend hundreds of millions of dollars on
machines that run PHP bytecode
On 19-11-2010, Goswin von Brederlow goswin-...@web.de wrote:
Sylvain Le Gall sylv...@le-gall.net writes:
On 19-11-2010, Goswin von Brederlow goswin-...@web.de wrote:
Sylvain Le Gall sylv...@le-gall.net writes:
On 18-11-2010, Goswin von Brederlow goswin-...@web.de wrote:
Not that much, if you
The program I am testing it on is basically a DFS algorithm so it doesn't
use much heap memory really. Just a lot of transient objects.
Looking at the top the RSIZE looks to be not over 11M under OSX.
Yes, the default minor heap size was indeed too low, I've been trying to set
it to a higher
On 11/16/2010 05:49 AM, David Allsopp wrote:
ExtLib is well-worth having and it's very easy to install (just run
ocaml install.ml in its source tree - findlib recommended but I've
got a feeling that it can install without findlib as well). It's also
very stable, feature-wise, so you're not
28 matches
Mail list logo
