<fasta>
You mean that the OCaml compiler basically just has falled behind?
<fasta>
fallen*
<fasta>
It's not like gcc takes a lot of time to compile it either.
<adrien>
yes, and GCC does take a lot of time to optimize; that's something you see with bigger files
<fasta>
Actually...
<fasta>
It seems they are completely different programs.
<Qrntz>
fasta, how did you track the running time?
<fasta>
Qrntz: I just used time.
<fasta>
I see a huge difference.
<fasta>
Ocaml needs to allocate lots of stuff at run-time.
<Qrntz>
I did the same and I see a ~20ms difference
<fasta>
In C that's part of the text segment.
<fasta>
Or well, I don't know that.
<Qrntz>
nothing close to «15 times faster» on my machine
<fasta>
Qrntz: AMD CPU?
<Qrntz>
no, intel c2d e6600
<fasta>
Qrntz: Intel Sandy Bridge here.
<fasta>
Qrntz: compiler version?
<fasta>
Qrntz: 4.6.3 here
<Qrntz>
4.6.3 as well
<fasta>
Qrntz: I used ocamlc -unsafe.
<Qrntz>
oh haha
<fasta>
Qrntz: ocaml.opt *
<Qrntz>
you do not measure bytecode against native code
<adrien>
hah :-)
<fasta>
Qrntz: er ocamlc.opt
<Qrntz>
here lies your problem
<Qrntz>
try ocamlopt
<Qrntz>
not ocamlc.opt
<fasta>
What is ocamlc.opt then?
<Qrntz>
keep the -unsafe
<Qrntz>
it is the native code executable of the bytecode compiler
<Qrntz>
the regular ocamlc is a bytecode executable
<Qrntz>
for portability sake
<adrien>
-unsafe helps for arrays
<fasta>
Why isn't it called ocaml_bytecode_compiler then?
<fasta>
That would be a lot easier :)
<adrien>
it's good to check without and with, but mostly a bad habit
<Qrntz>
so, there's a bytecode executable for compiling bytecode, a native executable for compiling bytecode, a bytecode executable for compiling native code and a native code executable for compiling native code
<Qrntz>
you used the second
<Qrntz>
you should've used the third or the fourth
<Qrntz>
it only matters if you value compilation time, they generate the same code
<fasta>
Qrntz: Still a factor of 2 difference.
<fasta>
Qrntz: but indeed, much better.
<Qrntz>
:-)
<fasta>
I think if the C program would the input size as input it would likely take about the same time.
<fasta>
When does 'time' start running?
<fasta>
After program load time, or before?
<Qrntz>
before, afaik
<K_F>
before, indeed
<Qrntz>
it can be influenced by disk caches
<Qrntz>
and such
<fasta>
If everything would be inlined, would that help?
ankit9 has quit [Ping timeout: 246 seconds]
<fasta>
I.e. I think a language like OCaml should be able to compile to that C code.
<fasta>
I don't consider that to be an unreasonable thing to expect.
<adrien>
output C code that can then be compiled by a C compiler?
<K_F>
well, all languages have their strengths and weaknesses..
<Qrntz>
you can try adjusting the inlining aggresiveness using the «-inline N» flag, but it probably won't help much
<fasta>
adrien: for example, if their register allocation is better.
<Qrntz>
I heard that 4.00 does inlining noticeably better, but I do not know the exact details
<fasta>
Is it possible to type printf "hello %s %s" 5 "world" in OCaml?
<fasta>
(Not a typo)
<fasta>
In the D programming language that actually works.
<Qrntz>
if in doubt, recall Xavier's axiom: «OCaml delivers at least 50% of the performance of a decent C compiler»
<Qrntz>
no, that won't work
<Qrntz>
it verifies types
<fasta>
Qrntz: but in D it just derives that you want to call print_int, or whatever it is called.
<fasta>
Qrntz: so, still type safe.
<Qrntz>
but that's D.
<fasta>
Qrntz: sure, and I think it's quite practical that it does that.
<Qrntz>
I don't really understand why wouldn't one just «printf "hello %d %s" 5 "world"»
<fasta>
D and OCaml seem to be about the same.
<adrien>
fasta: that wouldn't bring better performance
<fasta>
adrien: when compared to what?
<adrien>
GCC compiles C code, written by users
<adrien>
s/users/people/
<adrien>
machine-generated code is different
<fasta>
adrien: yes, and I think that for such 'imperative' code, it should be able to create human looking code.
<adrien>
moreover, it doesn't properly handle tail-recursion
<adrien>
that would kill the language unless some dirty workarounds are added
<adrien>
and they would in turn make everything slower
<adrien>
fasta: no, it shouldn't
<fasta>
adrien: you might be right regarding the whole 'it would make the compiler slow'-argument.
<fasta>
adrien: or even 'you are probably right'.
<adrien>
not compiler: compiled output
<fasta>
adrien: isn't it easy to see the correspondence between the two programs?
<adrien>
compiling would probably be slower too but the bigger issue is that thre are some constructs which OCaml programers use all the time and which wouldn't be properly handled by something like GCC
<Qrntz>
fasta, if you want an ML-like language that readily translates to C, try ATS
<Qrntz>
OCaml is not one
<fasta>
Qrntz: yeah, I am sort of a 'fan' of ATS, except for its syntax.
<fasta>
Qrntz: partly because of my linear logic familiarity.
<Qrntz>
s@yntax
<fasta>
Yeah.
<fasta>
I mean: who makes up that stuff?
<fasta>
That's a rhetorical question.
<K_F>
nothing beat INTERCAL :)
<fasta>
I think being precise about what you mean is good.
<fasta>
I.e. 'this object lives for exactly this long'.
<fasta>
This runs in exactly 100ms.
<fasta>
"This terminates".
<fasta>
"This computes an object with the following properties."
sepp2k has joined #ocaml
justdit has quit [Ping timeout: 248 seconds]
justdit has joined #ocaml
oxc has joined #ocaml
oxc has quit [Quit: oxc]
tumdum has joined #ocaml
tbrady has joined #ocaml
rudi_ has left #ocaml []
rgrinberg has joined #ocaml
emmanuelux has joined #ocaml
emmanuelux has quit [Remote host closed the connection]
Submarine has joined #ocaml
Submarine has quit [Changing host]
Submarine has joined #ocaml
emmanuelux has joined #ocaml
emmanuelux has quit [Remote host closed the connection]
<adrien>
when using godi, lablgtk's package using git always installs everything in site-lib, not pkg-lib
<adrien>
I don't understand why, any idea?
justdit has quit [Ping timeout: 252 seconds]
eikke has quit [Ping timeout: 256 seconds]
agumonkey has joined #ocaml
ankit9 has joined #ocaml
eikke has joined #ocaml
tbrady has quit [Quit: tbrady]
<fasta>
adrien: do you know how Ocsigen obtains persistent client programs?
<fasta>
adrien: or even what they actually mean by that in technical terms?
<adrien>
don't know
<fasta>
adrien: I don't know what the difference is between site-lib and pkg-lib, but assuming you are right, likely just ignorance/lack of time on whoever packaged it?
eni has joined #ocaml
<adrien>
I did work on the packaging and it's something godi is supposed to do automatically
<adrien>
as for pkg-lib vs. site-lib, pkg-lib is for libs installed through godi, while site-lib is for others
fraggle_ has joined #ocaml
ankit9 has quit [Quit: Leaving]
Progster has joined #ocaml
eni has quit [Ping timeout: 248 seconds]
Kakadu has quit [Quit: Konversation terminated!]
Kakadu has joined #ocaml
pango has quit [Ping timeout: 252 seconds]
pango_ has joined #ocaml
Kakadu has quit [Read error: Connection reset by peer]
Arsenik has joined #ocaml
Kakadu has joined #ocaml
Cyanure has quit [Read error: Connection reset by peer]
BiDOrD_ has joined #ocaml
BiDOrD has quit [Ping timeout: 255 seconds]
eni has joined #ocaml
pango_ is now known as pango
Progster has quit [Ping timeout: 272 seconds]
eni has quit [Read error: Connection reset by peer]
eni has joined #ocaml
tumdum has quit [Quit: tumdum]
avsm has joined #ocaml
tbrady has joined #ocaml
<tbrady>
I have a program where mark_slice eats the most time, 12.8% specifically according to gprof. Is this a common figure?
<adrien>
yes and no
<adrien>
usually the GC isn't the bottleneck
<adrien>
but it's not something that never happens either
<fasta>
tbrady: is it a graph algorithm?
<tbrady>
fasta: no, it's a financial thing. Kind of a foldl over a large text file.
<fasta>
tbrady: still 12% is not that much.
<tbrady>
Is it worth experimenting with the Gc module?
<fasta>
tbrady: I would only worry about it when it is over 30% myself.
<adrien>
tbrady: as fasta said, it's not your biggest concern
<adrien>
it's good to know about GC settings however, but you won't get anything significantly faster here
<flux>
tbrady, it can help adjusting the GC parameters
<flux>
however, the defaults have been upped some time in near history
<flux>
so it's probably less likely to help nowadays
<flux>
unless you have a problem that creates a lot of data that could be thrown in a minor collection if the limits just were increased a bit..
<adrien>
adjusting the values typically helps when you have lots of allocation and can spend some more memory
<tbrady>
I'm curious because, for this use case I don't need gc at all. the data are always smaller than memory, so I'd turn it off entirely if I could.
<adrien>
when I make the GC use more memory (do less work), I also return it to its previous settings once the code that allocates a lot is over
<flux>
tbrady, well in that case you could have GC activate even more rarely
<adrien>
tbrady: memory fragmentation, and "temporary" values
<flux>
tbrady, do notice that you probably do create garbage a lot, death by thousnad cuts ;)
<adrien>
but could we see gprof's output?
<tbrady>
flux: how do I have it active less?
<adrien>
yeah, if collections get triggered, it's because there was been garbage
<flux>
tbrady, probably by increasing the numbers minor_heap_size and space_overhead with the Gc module
<adrien>
it'll also increast latency when collecting
<fasta>
tbrady: if you have infinite memory, it never runs.
<flux>
surely you will need to tell ocaml gc first that you have infinite memory..
<fasta>
tbrady: another way is to restructure a part of your program such that there are no allocations.
<fasta>
Is that even possible in OCaml?
<adrien>
let a = 3,4
<flux>
it is, but it's going to be impractically limited
<adrien>
allocates
<flux>
adrien, but if you have for a = 1 to 10 x.(a) <- x.(a) + 1; done; does that allocate?
<flux>
(+do)
<adrien>
no idea :P
<adrien>
I guess something like that could still do allocations because of boxing
<fasta>
I think the best thing is still an interpreter like compiler and a sufficiently smart one.
<fasta>
THe SSC runs when you are sleeping.
<fasta>
I suppose that's an advantage of using SML.
<fasta>
But... I don't really see mlton back in the language shootout.
<fasta>
Is that because whole program compilation isn't that great?
<fasta>
I.e. it depends more on other details of the compiler?
<adrien>
languages like ATS and MLton would be faster for many of the things we've mentionned afaik
<adrien>
mlton is slow as hell when it comes to building however
<adrien>
I gave up after compiling "hello world"
<fasta>
Yes, which is why you should never have it as a development compiler.
<fasta>
adrien: it's not that slow.
<adrien>
mlton makes g++ -O3 on a 486 look fast
<fasta>
adrien: but yes, compared to ocaml or gcc it's terrible.
<fasta>
It's good in that it trades human time for CPU time.
* adrien
has been spoiled by ocaml
<fasta>
But only when you don't notice that it is running.
<fasta>
So, e.g. it has to run on some separate machine.