Hi,
atm we compile out large ocaml application (Astree, http://www.astree.ens.fr/)
with ocaml + MSVC64.
I would like to go away from MSVC to mingw, to e.g. have gdb available and
more unix like environment.
Atm it seems only the normal mingw (32bit) is supported.
I found some problem with usin
I apologize beforehand if this is not the forum to ask.
I am on the fence about whether to learn OCaml or not, and while
reading an article called "Why OCaml"
(http://www.cs.ubc.ca/~murphyk/Software/Ocaml/why_ocaml.html), I saw
that OCaml was praised for the speed of the executables it generates -
If you want speed then you should learn assembly or choose C as a second
choice.
It depends on the kind of apps you'd like to write. Even though O'Caml is
fast, it's not the first criteria I have in mind which would be security :
no segfault, no need to handle horrible stuff like in C, ...
2010/1
On Mon, Nov 22, 2010 at 2:35 PM, Gregory Bellier
wrote:
> If you want speed then you should learn assembly or choose C as a second
> choice.
> It depends on the kind of apps you'd like to write. Even though O'Caml is
> fast, it's not the first criteria I have in mind which would be security :
> no
Gregory Bellier wrote:
If you want speed then you should learn assembly or choose C as a second
choice.
Certainly not assembly. Modern microprocessors just see assembly as a
kind-of high level language which they interpret in a funny way, doing
all sorts of re-schedulings, register renamings,
Hello,
On 22-11-2010, Thanassis Tsiodras wrote:
> I apologize beforehand if this is not the forum to ask.
>
> I am on the fence about whether to learn OCaml or not, and while
> reading an article called "Why OCaml"
> (http://www.cs.ubc.ca/~murphyk/Software/Ocaml/why_ocaml.html), I saw
> that OCam
Hi,
> I am on the fence about whether to learn OCaml or not, and while
> reading an article called "Why OCaml"
> (http://www.cs.ubc.ca/~murphyk/Software/Ocaml/why_ocaml.html),
> I saw that OCaml was praised for the speed of the executables it
> generates - and was referred to, speed-wise, as "seco
Am Montag, den 22.11.2010, 15:21 +0200 schrieb Thanassis Tsiodras:
> I apologize beforehand if this is not the forum to ask.
>
> I am on the fence about whether to learn OCaml or not, and while
> reading an article called "Why OCaml"
> (http://www.cs.ubc.ca/~murphyk/Software/Ocaml/why_ocaml.html),
On 22-11-2010, Gerd Stolpmann wrote:
> Am Montag, den 22.11.2010, 15:21 +0200 schrieb Thanassis Tsiodras:
>> I apologize beforehand if this is not the forum to ask.
>>
>> I am on the fence about whether to learn OCaml or not, and while
>> reading an article called "Why OCaml"
>> (http://www.cs.ub
On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann wrote:
> 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
On Mon, 22 Nov 2010 15:36:30 +0100
bluestorm wrote:
> On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann
> wrote:
>
> > 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 enthusias
Am Montag, den 22.11.2010, 15:36 +0100 schrieb bluestorm:
> On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann
> wrote:
> 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
>
On 2010-11-21, at 20:26, Eray Ozkural wrote:
> I've been thinking whether some kind of doubling strategy would work for the
> minor heap size. What do you think?
Sounds like an interesting idea, but what heuristic would you use?
When everything is smooth, the running time decreases something li
On 2010-11-22, at 13:04, Christoph Cullmann wrote:
> In ocaml 3.12, in byterun/major_gc.h, there is:
>
> intnat caml_major_collection_slice (long howmuch)
>
> whereas in the .c file that is:
>
> intnat caml_major_collection_slice (intnat howmuch)
>
> As intnat is with mingw-w64 long long, thi
Török Edwin writes:
> On Mon, 22 Nov 2010 15:36:30 +0100
> bluestorm wrote:
>
>> On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann
>> wrote:
>>
>> > 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
>> > r
On Mon, Nov 22, 2010 at 04:10:49PM +0100, Damien Doligez wrote:
> On 2010-11-21, at 20:26, Eray Ozkural wrote:
>
> > I've been thinking whether some kind of doubling strategy would work for
> > the minor heap size. What do you think?
>
> Sounds like an interesting idea, but what heuristic would
On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann wrote:
> So maybe a good opportunity to post better Ocaml solutions there?
I spent some time improving OCaml solutions, and most of the time, my
solutions were refused: the organizers don't let you unroll loops, fix
GC parameters, etc. One strength
On 22-11-2010, Damien Doligez wrote:
>
> On 2010-11-21, at 20:26, Eray Ozkural wrote:
>
>> I've been thinking whether some kind of doubling strategy would work for the
>> minor heap size. What do you think?
>
> Sounds like an interesting idea, but what heuristic would you use?
> When everything i
2010/11/22 Török Edwin :
> 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.
The
Zitat von "Gerd Stolpmann" :
[...]
(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?
[...]
Yes I also remember that.
I hope that the new OCaml compilers did not
make OCaml lessperformance by enhancing othe
I can confirm that old code-snippets were removed (and that both faster
solutions and environment variable tweaks were rejected).
On Nov 22, 2010, at 6:02 PM, Oliver Bandel wrote:
> Zitat von "Gerd Stolpmann" :
> [...]
>> (I remember Ocaml was #1
>> at the shootout a few years ago, faster than C
answer to the original poster:
ocaml is surprisingly fast for such a high level language, i like this
insight/comparison:
http://youinfinitesnake.blogspot.com/2010/09/programming-language-wars-movie.html
(even if the benchmarks can be improved reading others posts of this
thread)
__
...hmhhh..
...looks like they are biased...
not that we are not ;)
...but... as the GC-stuff is available FROM WITHING the language,
in the standard-lib, this is nothing added on later.
And I think it should also be allowed to be used.
To reject environment variables, I can see as acc
Note: I'm not saying that they are biased. It's quite possible they did the
same thing for other languages, too, I didn't take the time to check.
On Nov 22, 2010, at 6:23 PM, Oliver Bandel wrote:
>
> ...hmhhh..
>
> ...looks like they are biased...
>
>
> not that we are not ;)
_
On Mon, Nov 22, 2010 at 6:42 PM, Sylvain Le Gall wrote:
> On 22-11-2010, Damien Doligez wrote:
> >
> > On 2010-11-21, at 20:26, Eray Ozkural wrote:
> >
> >> I've been thinking whether some kind of doubling strategy would work for
> the minor heap size. What do you think?
> >
> > Sounds like an in
Hi,
Zitat von "Thanassis Tsiodras" :
I apologize beforehand if this is not the forum to ask.
I am on the fence about whether to learn OCaml or not, and while
reading an article called "Why OCaml"
(http://www.cs.ubc.ca/~murphyk/Software/Ocaml/why_ocaml.html), I saw
that OCaml was praised for th
On Mon, 22 Nov 2010 17:46:49 +0100
Fabrice Le Fessant wrote:
> 2010/11/22 Török Edwin :
> > 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, a
> When everything is smooth, the running time decreases something like
> exponentially with the minor heap size, so you'd always want to
> increase the size. How do you tell when to stop? And then, if the
> program is not behaving uniformly, when do you decide to reduce
> the size?
I don't unde
What happens if you just increase the default size?
___
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_beginne
On Mon, Nov 22, 2010 at 11:14 PM, Jon Harrop <
jonathandeanhar...@googlemail.com> wrote:
> What happens if you just increase the default size?
>
>
Well we don't want to be a memory hog like Java do we? It's something that
kind of depends on the app, what would you set it to?
Cheers,
--
Eray Oz
It's always funny to look at benchmarks made by amateurs. We get it all the
time in parallel computing, when some sharp programmer decides to implement
a parallel algorithm in Java. :) I keep asking myself questions like do you
also program ciphers in Flash? Graph algorithms in PHP?
In my experien
On Mon, Nov 22, 2010 at 06:23:38PM +0100, Oliver Bandel wrote:
> ...looks like they are biased...
> not that we are not ;)
> To reject environment variables, I can see as acceptable in this case,
> but rejecting the GC-stuff does not make sense, because, as just mentioned,
> it is avalable
Thanassis Tsiodras gmail.com> writes:
-snip-
> Is it just hype, then? Or am I missing something?
Note the "Why Ocaml?" date - December 2002.
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-li
David Rajchenbach-Teller univ-orleans.fr> writes:
> I can confirm that old code-snippets were removed (and that both faster
solutions and environment
> variable tweaks were rejected).
Even back in 2001, Doug Bagley had noted all the things that were
wrong with the tasks on his "The Great Compu
2010/11/20 Yoann Padioleau :
> Do we have example of big companies porting their whole codebase to another
> language ?
Linspire? The distro ERS went to work, formely Lindows. They had
everything in OCaml and then rewrote to Haskell. It seems to me that
OCaml wasn't functional enough.
It seems t
Gerd Stolpmann gerd-stolpmann.de> writes:
-snip-
> 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 v
bluestorm gmail.com> writes:
-snip-
> 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 measure
Dario Teixeira yahoo.com> writes:
-snip-
> There's lies, damn lies, and shootout statistics.
-snip-
After all, facts are facts,
and although we may quote one to another with a chuckle
the words of the Wise Statesman, 'Lies--damned lies--and statistics,'
still there are some easy figures the simp
38 matches
Mail list logo
