Modius has quit [Read error: Connection reset by peer]
Modius has joined #ocaml
jamii has quit [Ping timeout: 276 seconds]
edwin has joined #ocaml
larhat has joined #ocaml
worstadmin has joined #ocaml
ftrvxmtrx has quit [Quit: This computer has gone to sleep]
ftrvxmtrx has joined #ocaml
ftrvxmtrx has quit [Client Quit]
ikaros has joined #ocaml
edwin has quit [Remote host closed the connection]
avsm^away is now known as avsm
sgnb has quit [Remote host closed the connection]
ftrvxmtrx has joined #ocaml
sgnb has joined #ocaml
Snark has quit [Remote host closed the connection]
alfa_y_omega has quit [Ping timeout: 250 seconds]
alfa_y_omega has joined #ocaml
ikaros has quit [Quit: Ex-Chat]
eikke has joined #ocaml
<eikke>
hija
<eikke>
is there any tool to profile allocations in ocaml? as in -> profile which types of objects are allocated and GC'ed
<eikke>
I have a very basic app which shouldnt do much memory-related things, but when time-profiling it, I get +- 30% of time (runtime of less than a second in total) spent in GC
Cyanure has joined #ocaml
<flux>
there are some memory usage analysis tools, but I haven't used them
<flux>
fidling with the GC parameters is likely to help you
<flux>
the defaults are quite conservative
<flux>
increasing the minor heap and/or the overhead for example are good things to try
<eikke>
I found ocamlviz, but that seems to give real-time introspection of value types
<eikke>
which doesnt work for me since I cant read those values in <1s :D
<flux>
if you just want your short-lived program to run as fast as possible, you could just up all the limits to the extreme
<flux>
then it should take no time in GC :)
<eikke>
that wont help :) the 'app' is a little testsuite for a library/component I'm working on, which will be used in long-running applications
<flux>
I don't see why it wouldn't help, if you're checking for correctness of an O'Caml program - it wouldn't affect it
<flux>
unless you use weak references or something..
<eikke>
I cant rely on changing global GC settings, since the app in which the lib is hosted might need more conservative GC behaviour
<flux>
you can adjust GC parameters with the environment variable OCAMLRUNPARAM as well
ftrvxmtrx has quit [Ping timeout: 260 seconds]
<f[x]>
_habnabit, if you are using ocamlgsl debian package mind that native version is build without debug
<f[x]>
this is probably a bug worth reporting
<f[x]>
_habnabit, after rebuilding with debug backtrace points at gsl_error.ml line 54
<f[x]>
the question why bytecode and native have different behaviour needs further investigation
f[x] has quit [Read error: Connection reset by peer]
f[x] has joined #ocaml
Amorphous has quit [Ping timeout: 255 seconds]
Amorphous has joined #ocaml
edwin has joined #ocaml
alfa_y_omega has quit [Ping timeout: 246 seconds]
alfa_y_omega has joined #ocaml
meltem has joined #ocaml
alfa_y_omega has quit [Ping timeout: 276 seconds]
alfa_y_omega has joined #ocaml
wagle has quit [Ping timeout: 258 seconds]
thelema_ has quit [Ping timeout: 240 seconds]
wagle has joined #ocaml
thelema has joined #ocaml
alfa_y_omega has quit [Ping timeout: 240 seconds]
lopex has joined #ocaml
alfa_y_omega has joined #ocaml
_andre has joined #ocaml
ftrvxmtrx has joined #ocaml
Anarchos has joined #ocaml
<f[x]>
is it ok to raise exceptions or alloc from external "float" functions?
<flux>
I would like to say 'yes', because I've only heard about that limitation in relation to "noalloc" functions
<flux>
but I don't even know what "float" functions are :-)
<flux>
sin etc are "float"?
alfa_y_omega has quit [Ping timeout: 240 seconds]
<f[x]>
yep
<f[x]>
see pervasives.ml
alfa_y_omega has joined #ocaml
lamawithonel has quit [Remote host closed the connection]
Cyanure has quit [Ping timeout: 240 seconds]
alfa_y_omega has quit [Ping timeout: 246 seconds]
alfa_y_omega has joined #ocaml
alfa_y_omega has quit [Max SendQ exceeded]
alfa_y_omega has joined #ocaml
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
alfa_y_omega has quit [Ping timeout: 244 seconds]
worstadmin has quit [Ping timeout: 240 seconds]
lamawithonel has joined #ocaml
alfa_y_omega has joined #ocaml
dnolen has joined #ocaml
_nejimban has joined #ocaml
alfa_y_omega has quit [*.net *.split]
nejimban has quit [*.net *.split]
_nejimban is now known as nejimban
<thelema>
f[x]: can you disable the batteries build under 3.10? (qemu-armel-debian,default) Batteries needs 3.11 to compile
<f[x]>
thelema, done
alfa_y_omega has joined #ocaml
<thelema>
f[x]: thank you. I wonder why it chose now to fail - that code has been there since 2010
alfa_y_omega has quit [Excess Flood]
alfa_y_omega has joined #ocaml
alfa_y_omega has quit [Ping timeout: 255 seconds]
<f[x]>
strange
alfa_y_omega has joined #ocaml
dnolen has quit [Quit: dnolen]
alfa_y_omega has quit [Excess Flood]
alfa_y_omega has joined #ocaml
alfa_y_omega has quit [Max SendQ exceeded]
alfa_y_omega has joined #ocaml
alfa_y_omega has quit [Ping timeout: 255 seconds]
alfa_y_omega has joined #ocaml
Obfuscate has quit [Ping timeout: 246 seconds]
Obfuscate has joined #ocaml
eikke has quit [Read error: Operation timed out]
lopex has quit []
eikke has joined #ocaml
ztfw has joined #ocaml
iratsu has quit [Ping timeout: 250 seconds]
iratsu has joined #ocaml
larhat has quit [Quit: Leaving.]
Cyanure has joined #ocaml
lopex has joined #ocaml
lopex has quit [Client Quit]
lopex has joined #ocaml
ikaros has joined #ocaml
sepp2k has joined #ocaml
<_habnabit>
f[x], I'm building everything with godi on OS X.
<_habnabit>
f[x], are you the maintainer for ocamlgsl, or an interested party? (just curious.)
joewilliams_away is now known as joewilliams
<f[x]>
_habnabit, more of a passer-by
<f[x]>
notice that adding print_endline after try fixes thing
<f[x]>
I suspect that it is forbidden to raise exceptions from "float" external functions (that's how it is declared by ocamlgsl)
<_habnabit>
does it? let me try.
<_habnabit>
'after the try' meaning in the `try` block?
<f[x]>
yup
<f[x]>
or maybe it is ocamlopt bug :)
<_habnabit>
oh. did you see the paste that I made?
<_habnabit>
because I'm still seeing the same issue.
<thelema>
f[x]: the no exceptions from "float" externals makes sense - float seems to imply a desire for speed, and changing the ABI for this would likely pull out exception returns
<_habnabit>
oh, adding the print_endline /before/ it.
<f[x]>
thelema, but why? iiuc raising exception means looking up the stack of exception handlers which is already setup before call to "float"
eikke has quit [Ping timeout: 252 seconds]
<thelema>
ah, maybe I misunderstood exceptions
<f[x]>
I am not sure either
<_habnabit>
... oh, wacky.
<_habnabit>
that does fix it.
<f[x]>
I think this qualifies for caml-list
<_habnabit>
that is baffling.
alexyk has joined #ocaml
avsm1 has joined #ocaml
avsm has quit [Read error: Connection reset by peer]
<mfp>
f[x]: I believe you can't raise an exception from a "float" function; after all, that implies allocation, which would require the call to go through caml_c_call
ulfdoz has joined #ocaml
<f[x]>
and "float" doesn't setup registers the way caml_c_call expects?
<mfp>
it calls the function directly AFAIK
<f[x]>
oops, I mean allocation requires some setup that is not done by "float" - right?
<thelema>
float implies noalloc?
<mfp>
that's what I meant, yes
<f[x]>
if so - then ocamlgsl is awfully broken
<mfp>
but I'm not so sure after looking at the assembly for external foo : float -> float = "foo" "float" let f x = foo x
<mfp>
sin x is a mere call sin@PLT though
<mfp>
oops, got the external syntax wrong
* f[x]
can reproduce the issue without gsl
<mfp>
this makes more sense > external foo : float -> float = "foobar_1" "foobar_2" "float" let f x = foo x
<mfp>
so I'd conclude you cannot allocate in "float" functions (avoiding the allocation (float boxing) is the very point)
<f[x]>
why?
<f[x]>
allocation requires single register pointing to heap
<f[x]>
and it is not eax
<mfp>
because it's not going through caml_c_call, as other non-noalloc functions
<mfp>
caml_c_call does this amongst other things before calling the C function -> /* Make the exception handler and alloc ptr available to the C code */ STORE_VAR(%r15, caml_young_ptr) STORE_VAR(%r14, caml_exception_pointer)
<f[x]>
ah
<mfp>
there's none of this if the call is direct, as happens in the above code
<f[x]>
now that makes perfect sense
<f[x]>
caml_exn_ptr is hoisted in register and so "float" func sees the old value of it
<f[x]>
and so exn is raised as if outside try block
<f[x]>
mfp, thanks a lot!
<mfp>
np
<mfp>
hmm now, one could conceive a "float-noalloc" function
<mfp>
oops, I meant "float-alloc"
<f[x]>
so now ocamlgsl is broken :)
<mfp>
that does caml_c_call's thing, but doesn't use boxed floats
<f[x]>
interesting
<mfp>
not sure if the use case is common enough to justify the change to the compiler, though
* f[x]
wonders whether it is possible to preallocate exn block and raise it without allocations
<f[x]>
from "float" func
<mfp>
hmm maybe it'd be possible to use caml_c_call _inside_ the stub function
<_habnabit>
that's incredible.
<_habnabit>
see, I just don't know how nobody noticed this until now. I couldn't find any mailing lists posts or anything about this issue.
<thelema>
_habnabit: often the register will have the correct value, if there was a regular C call since the last exception handler was registered
<_habnabit>
so, is the best workaround to make a regular C call before making this call?
<_habnabit>
like, define a no-op function just to call it?
<thelema>
or put the necessary setup inside the C function that raises an exception
ulfdoz has quit [Quit: deprecated]
<mfp>
if he could, he'd just have to remove the "float" external (and rearrange the function params/retvalue), so I guess the no-op C function that forces a caml_c_call is the easiest workaround
<f[x]>
I guess you can't do this at raise side because those registers can be overwritten by gsl C code
<mfp>
registers? caml_c_call saves registers in caml_xxxx variables
<thelema>
mfp: quite a terrible workaround
* f[x]
commented on "or put the necessary setup inside the C function that raises an exception"
<_habnabit>
hmm.
<thelema>
ok, so the right way is to not have float externals that raise exceptions.
<_habnabit>
heh.
* f[x]
thinks that preallocating the exn block should work
<f[x]>
ok, no, I don't think so
ftrvxmtrx has quit [Quit: This computer has gone to sleep]
<adrien>
what would be a quick way to make sure a function isn't inlined?
<thelema>
adrien: increase its code size
<thelema>
possibly with dead code that the compiler doesn't eliminate
<adrien>
how to be sure it doesn't get eliminated? ;-)
<thelema>
use a ref - minor runtime penalty for checking that ref, but it'll prevent elimination of code that depends on it.
<thelema>
if !false_ref then <lots of code>; assert false else <real code>
<adrien>
well, ok, I used a for loop from 1 to 40 and print_endline, and it didn't change anything to my segfault
<thelema>
there were some other compiler limitations that prevent inlining, but there's active work to remove them in the compiler.
<adrien>
(brb)
sepp2k has quit [Ping timeout: 255 seconds]
jderque has joined #ocaml
sepp2k has joined #ocaml
ikaros has quit [Ping timeout: 255 seconds]
ftrvxmtrx has joined #ocaml
ikaros has joined #ocaml
ulfdoz has joined #ocaml
ikaros has quit [Ping timeout: 260 seconds]
ankit9 has quit [Quit: Leaving]
ankit9 has joined #ocaml
jamii has joined #ocaml
ulfdoz has quit [Quit: deprecated]
ikaros has joined #ocaml
ulfdoz has joined #ocaml
ikaros has quit [Quit: Ex-Chat]
ankit9 has quit [Quit: Leaving]
Anarchos has joined #ocaml
lamawithonel has quit [Remote host closed the connection]
iratsu has quit [Quit: Leaving.]
jamii has quit [Ping timeout: 246 seconds]
lopex has quit [Ping timeout: 240 seconds]
_andre has quit [Quit: leaving]
lopex has joined #ocaml
edwin has quit [Remote host closed the connection]
<thelema>
also, function names in backtraces - it's a pain cross-referencing the stdlib by line/character pos
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
lopex has quit [Ping timeout: 260 seconds]
lopex has joined #ocaml
jderque has quit [Quit: leaving]
elehack has joined #ocaml
<thelema>
elehack: I think it's about time for another batteries release
eikke has quit [Quit: Lost terminal]
<elehack>
thelema: sweet!
* elehack
has been largely out-of-touch lately... most energy on Java coding @ school
<thelema>
I've also looked at the difference between 1.4 and 2.0, and 2.0 doesn't add much (we've been doing that in the 1.x series), but renames a bit a removes some things that should go away.
jamii has joined #ocaml
<thelema>
s/a removes/and removes/
<elehack>
has 2.0 see some UTF8 interface cleanup yet?
<elehack>
I know we've discussed that a bit in a github ticket
<thelema>
yes, 2.0 has the Unicode infrastructure replaced by ulib
<thelema>
ulib should probably be in libs/ instead of src...
<thelema>
it's not a perfect replacement - ulib keeps more of the original design, I only had to make minor tweaks to integrate it
<thelema>
batRope -> Ulib.Text, BatUTF8 -> Ulib.UTF8, that kind of thing
<thelema>
elehack: btw, are you interested in more statistically sound benchmarking than ocaml-benchmark?
<elehack>
I haven't used ocaml-benchmark, so I don't know.
<elehack>
then again, I've never tried to do robust ocaml benchmarking.
<thelema>
ok, not so interested. Just checking. I've been spending some time on a benchmarking library that goes so far as to measure clock resolution and the cost of getting the time.
<elehack>
that sounds quite interesting, but much more complex than my work ever mandates. My benchmarking and profiling needs are typically in the 10s of seconds accuracy department.
<thelema>
the other thing it'll do is analyze the pattern of timings and determine if the outliers contributed excessively to the variance of the result, skewing the results.
<elehack>
Now I could use one of those in Java...
<elehack>
sounds like a useful way to deal with early delays due to the JIT and various caches being cold.
<thelema>
the library I'm stealing good ideas from is Criterion, a haskell library. Haskell and Java both have horrible challenges for benchmarking.
<elehack>
yeah.
ztfw has quit [Remote host closed the connection]
lopexx has joined #ocaml
lopex has quit [Ping timeout: 258 seconds]
* elehack
needs to head home & see if he can get his laptop to stop crashing - ttylater
elehack has quit [Quit: Headed out, possibly to home]
sepp2k has quit [Quit: Leaving.]
lopexx has quit []
lopex has joined #ocaml
bzzbzz has quit [Ping timeout: 252 seconds]
bzzbzz has joined #ocaml
joewilliams is now known as joewilliams_away
<thelema>
Batteries 1.4.0 released, let the bug reports roll in
<thelema>
hmm, 1.4.0 < 1.4.0pre2 -- time to fix version comparator
lamawithonel_ has joined #ocaml
lamawithonel__ has joined #ocaml
lamawithonel_ has quit [Ping timeout: 255 seconds]
Cyanure has quit [Remote host closed the connection]
dnolen_ has joined #ocaml
joewilliams_away is now known as joewilliams
elehack has joined #ocaml
lamawithonel__ has quit [Remote host closed the connection]