jonafan has quit [Read error: 110 (Connection timed out)]
dwmw2_BOS has quit ["tin can..."]
hkBst has quit ["Konversation terminated!"]
ecc_ has joined #ocaml
goalieca has joined #ocaml
LordMetroid has quit [Connection timed out]
coucou747 has quit ["bye ca veut dire tchao en anglais"]
notyouravgjoel has quit ["This computer has gone to sleep"]
ecc_ has quit ["leaving"]
ecc has quit ["leaving"]
Tetsuo has quit ["Leaving"]
shortcircuit has quit [Read error: 110 (Connection timed out)]
mwc has joined #ocaml
ecc has joined #ocaml
Snrrrub__ has joined #ocaml
Snrrrub has quit [Connection timed out]
heash has joined #ocaml
heash has left #ocaml []
mrsolo has quit ["Leaving"]
xavierbot has quit [Read error: 110 (Connection timed out)]
Snrrrub__ has quit [Read error: 110 (Connection timed out)]
ben_ has joined #ocaml
shortcircuit has joined #ocaml
mrsolo has joined #ocaml
shortcircuit has quit [Read error: 110 (Connection timed out)]
ben_ has quit []
jeffwheeler has joined #ocaml
ecc has quit [brown.freenode.net irc.freenode.net]
mwc has quit [brown.freenode.net irc.freenode.net]
pattern has quit [brown.freenode.net irc.freenode.net]
bzzbzz has quit [brown.freenode.net irc.freenode.net]
petchema has quit [brown.freenode.net irc.freenode.net]
szell` has quit [brown.freenode.net irc.freenode.net]
Illocution has quit [brown.freenode.net irc.freenode.net]
jeremiah has quit [brown.freenode.net irc.freenode.net]
ikatz has quit [brown.freenode.net irc.freenode.net]
jdavis_ has quit [brown.freenode.net irc.freenode.net]
rwmjones has quit [brown.freenode.net irc.freenode.net]
Smerdyakov has quit [brown.freenode.net irc.freenode.net]
ecc has joined #ocaml
mwc has joined #ocaml
pattern has joined #ocaml
bzzbzz has joined #ocaml
petchema has joined #ocaml
szell` has joined #ocaml
rwmjones has joined #ocaml
Illocution has joined #ocaml
jeremiah has joined #ocaml
ikatz has joined #ocaml
jdavis_ has joined #ocaml
Smerdyakov has joined #ocaml
Nutssh has joined #ocaml
Smerdyakov has quit [brown.freenode.net irc.freenode.net]
ikatz has quit [brown.freenode.net irc.freenode.net]
Illocution has quit [brown.freenode.net irc.freenode.net]
bzzbzz has quit [brown.freenode.net irc.freenode.net]
mwc has quit [brown.freenode.net irc.freenode.net]
ecc has quit [brown.freenode.net irc.freenode.net]
petchema has quit [brown.freenode.net irc.freenode.net]
szell` has quit [brown.freenode.net irc.freenode.net]
rwmjones has quit [brown.freenode.net irc.freenode.net]
jdavis_ has quit [brown.freenode.net irc.freenode.net]
jeremiah has quit [brown.freenode.net irc.freenode.net]
pattern has quit [brown.freenode.net irc.freenode.net]
ecc_ has joined #ocaml
bzzbzz has joined #ocaml
pattern has joined #ocaml
ikatz has joined #ocaml
Illocution has joined #ocaml
petchema has joined #ocaml
jdavis_ has joined #ocaml
rwmjones has joined #ocaml
Smerdyakov has joined #ocaml
mwc has joined #ocaml
jeremiah has joined #ocaml
mwc has quit [Read error: 104 (Connection reset by peer)]
mwc has joined #ocaml
det has quit [Read error: 110 (Connection timed out)]
jeffwheeler has left #ocaml []
goalieca has quit [Remote closed the connection]
evn_ has joined #ocaml
goalieca has joined #ocaml
|Catch22| has quit []
evn_ has quit []
AxleLonghorn has joined #ocaml
shortcircuit has joined #ocaml
ben_ has joined #ocaml
AxleLonghorn has left #ocaml []
goalieca has quit [Remote closed the connection]
goalieca has joined #ocaml
bluestorm has joined #ocaml
ttamttam has joined #ocaml
mwc has quit ["Leaving"]
ita has joined #ocaml
ygrek has joined #ocaml
<TFK>
Memory-profiling, old-skool style - comment out code and see if it still leaks :D
<TFK>
It's not GSL, apparently. Which brings me back to the fact that I create lots and lots of small types ("genomes" from arrays).
<flux>
tfk, maybe you could add finalizers to suspicious blocks
<bluestorm>
small types, or small values ?
<flux>
and issue gc manually
<flux>
and check out which blocks don't get finalized
Linktim has joined #ocaml
<TFK>
bluestorm, the type is a genome length integer and a ~256-byte string.
<TFK>
Finalizers, I'll look into that.
<bluestorm>
hm, you encode different array lengths at the type level ?
<TFK>
What do you mean?
<bluestorm>
hm. i'll refrain from disturbing you by asking stupid questions about your code
<TFK>
That's OK, I ask stupid newbie questions here all the time ;-)
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
Amorphous has quit [Read error: 104 (Connection reset by peer)]
Amorphous has joined #ocaml
ben_ has quit [Read error: 110 (Connection timed out)]
<TFK>
flux, it appears that simply calling Gc.full_major alleviates most of the problem.
love-pingoo has joined #ocaml
<TFK>
Memory still rises though, but slowly...
<flux>
tfk, it still does suggest that you keep hold of something, if your actual memory requirements don't increase..
<flux>
tfk, maybe you could adjust the gc parameters to get better behavior
Tetsuo has joined #ocaml
bongy has joined #ocaml
<bluestorm>
TFK: do you have some relatively simple code to show ?
<TFK>
It's 700 lines
<bluestorm>
btw. , have you used Gc.print_stat yet ?
<TFK>
Not yet.
<bluestorm>
imho it's a bit verbose if you're not familiar with those GC-things, but quite useful
goalieca has quit ["(keep your stick on the ice)"]
<TFK>
flux, how would I tweak the GC to make it run more often (which is apparently what I need, using Gc.create_alarm a major cycle isn't run until I call it... why?)?
<flux>
tfk, dunno, have you checked out the parameters?-)
<flux>
there should be some thresholds you can adjust..
<TFK>
bluestorm, nope. Anyway, doesn't a major collection execute a minor collection as well?
<pango>
that's the other way around, minor collection is followed by a slice of the major collection
<bluestorm>
yes, but it's overkill if the data you want to collect is only in the "recent objects" pool
<bluestorm>
wich is usually the case
<TFK>
Hmm, live_words doesn't appear to grow. I guess Ubuntu's System Monitor is leading me astray?
<bluestorm>
what about minor_words ?
<TFK>
Is growing, but it's also the stuff that's already been collected, no?
<bluestorm>
isn't
<bluestorm>
a gross picture would be : it's a two-generation GC, you've two pool of live objects : the minor, where you've got the young and little objects, and the major, where you have to old, big objects
<bluestorm>
allocated values start in the minor pool, and if they survived some minor collections, they got "promoted"
<bluestorm>
that's useful because in functional programming, you allocate a lot of small object with a very short life
<bluestorm>
thus, frequent minor collections are very useful, and they do not have to scan the pool of older objects, wich are less likely to get freed
<pango>
actually increasing minor heap to make them less frequent can give better performance
<TFK>
Well, it appears that in between me invoking minor collections, some stuff gets promoted, and RAM usage still grows.
<bluestorm>
TFK: if you have a *leak*
<flux>
bluestorm, hmm, for a game, would it be a bad idea to cal Gc.minor () after each drawn frame? (drawing a frame may require constructing quite a few temporary objects)
<bluestorm>
you can't handle it by GC-tuning only
<TFK>
bluestorm, or if I'm not invoking a major collect, as I understand it.
<pango>
because it lowers to ratio of promoted objects, and lessen major collection's work
<bluestorm>
pango: what i've tried on a few code of mine that had problems of GC overwork
<TFK>
Anyway, minor collects *are* getting called constantly, no matter what I do (at least print_stats says so).
<bluestorm>
was to increase the minor_heap_size
<bluestorm>
(and the major_heap_increment)
<pango>
TFK: size of major collection's slices should be driven by space_overhead
<bluestorm>
you should lessen space_overhead
<bluestorm>
it's a percentage, so try 60 for example
<TFK>
I'll do that.
<bluestorm>
(default is 80)
<bluestorm>
but if you do that, the GC will have to work more, so you'll have a bit more CPU usage
<bluestorm>
flux: i think the GC can handle that himself
<TFK>
Better than blasting my RAM away ;-)
<flux>
I've had one case where I had to adjust Gc parameters to reduce cpu consumption.. I'm just wondering if a well-put explicit minor collection would've helped as much.
<bluestorm>
hm
<bluestorm>
in the gc-use-your-cpu case i've seen, i actually allocated a lot of long-lived objects
<pango>
flux: explicitly calling the gc most often results in lower performance
<bluestorm>
and the cpu waste was caused by little promotions occuring too often
<flux>
at each cycle the program discarded all the memory it had allocated
<bluestorm>
so as pango say, the way to handle that was to actually increase the minor slices work, so that they would run less often
<bluestorm>
+s
<flux>
so in theory if the gc was well-placed, there would be very few roots to follow
<flux>
wouldn't that make the gc fast?
<bluestorm>
hm, you could try
<bluestorm>
i guess it really depends on the project you have
<pango>
flux: the only reason, in a game, could be to try to avoid collection happening at a "wrong time" (visible latency), but that looks like deep magic
* pango
wonders if, say, freetennis, explicitly calls the gc
<flux>
actually it was a different problem in the case I had in my mind.. I solved its performance problem with Gc.minor_heap_size = 1 lsl 18, I guess the default minor heap size is smaller?
<bluestorm>
hm
<flux>
I tried out without that change, with that change and without that change with explicit Gc.minor; only the middle one produced an effect
<bluestorm>
i have used even bigger value
<flux>
I think I found that value by iteration
<bluestorm>
at the cost of increased memory consumption, i got quite major performance impromevent
<bluestorm>
(i use 22 to 24 iirc)
<flux>
anyway, the problem existed only because the cpu was 200MHz and the program was pegging the cpu; the from from 15% to 13% is hardly relevant on modern hardware. but I guess at times it could have a larger effect.
<bluestorm>
flux: this kind of minor-collection-related slowdown can be seen easily when profiling
<bluestorm>
(native profiling, i mean)
<bluestorm>
when your first time-consuming function is gc-related
<flux>
yes, that's how I found it
<flux>
it still did consume a lot cpu, though
<flux>
which is sort of ridicilous when a "mark" and "release"-kind of memory management would be able to do the same with 0% overhead ;)
<flux>
has region inference found itself into any compilers other than mlkit?
<bluestorm>
haven't heard of any
<flux>
theoretically that should do it.. if lucky.
<flux>
but I wouldn't mind if I had to manually annotate some pools, maybe that would give the compiler a better chance
<TFK>
space_overhead does seem to help in that a full major cycle is eventually called, but live_words stays the same o_O
<pango>
in compaction hels but major collection doesn't, maybe you have a bad case of memory fragmentation
<pango>
s/in/if/
<TFK>
compaction never got executed anyway
ita is now known as ita|zzz
<TFK>
when I called full_major manually, live_words stayed constant without any compactions.
<TFK>
hmmm, if live_words remain constant but fragments are rising, will it still indicate an increase in RAM usage in the System Monitor?
* Yoric[DT]
has never looked at the internals of OCaml's gc.
<flux>
tfk, how long are you running the program?
<TFK>
a few minutes?
<TFK>
Eventually it should run a few hours.
<pango>
I think ram usage should more or less follow heap_words metric
<pango>
that could depend on underlying malloc()/free() implementation
<love-pingoo>
(unless you're interfacing with some C code of course)
<TFK>
heap_words remain constant if I call major_collect all the time.
<pango>
yes, there's also out-of-heap allocations
<TFK>
Let me try that without GSL, then.
<love-pingoo>
is it a large program ? can we have a look ?
<flux>
could the GSL bindings have a bug?
<love-pingoo>
if you don't have any C code around, there should be a simple (high-level) explaination
<TFK>
It's 700 lines of code, it's logically not difficult but I doubt you'd want to look at it.
<love-pingoo>
sounds too large for a quick glance, yup
<flux>
tfk, I think your best (well, easiest) bet would be to proceed chatting with the guy who wrote/ported the heap debugger, and find out how to make it work for you :)
<TFK>
heh...
<love-pingoo>
oh, we used that heap debugger
<TFK>
and who wrote it?
<TFK>
oh, you mean heapstats
<love-pingoo>
fabrice le fessant
<TFK>
Does he speak English?
jderque has joined #ocaml
<love-pingoo>
sam had to write a patch for it to work on 3.10 (or was it 3.09)
<love-pingoo>
TaXules: yes he does :)
<TFK>
I guess I'll write him, then...
<love-pingoo>
but really, going to heapstat should be the last attempt
<flux>
why? it could almost instantaneously point to the right direction?
<love-pingoo>
it's painful to use and it doesn't help if the problem is on the C side
<flux>
it would point out that too, no?
<flux>
I haven't tried to use it, so I don't know about that.. it does require recompiling everything (?) with it, though?
<TFK>
Anyway, substituting GSL for OCaml's Random doesn't help.
<love-pingoo>
it would tell you how many custom blocks of which kind are allocated
<love-pingoo>
but doesn't inspect inside them
<flux>
I suppose if it's only a single module tfk is developing, it wouldn't help much
<love-pingoo>
TFK: what kind of program is it ?
<TFK>
I'm porting Nanopond, an Artificial Life simulator, to OCaml.
<love-pingoo>
so you're creating lots of entities and have them live
<TFK>
The port is basically ready (as it was half a year ago), but yesterday I finally got around looking into its peculiar RAM usage.
<love-pingoo>
then they die
<TFK>
Yes, I'm creating lots and lots of objects.
<love-pingoo>
sure they can be reclaimed by the GC once dead ?
<TFK>
More specifically, I'm converting Arrays to "genome" and vice versa.
<love-pingoo>
no global table of all entities ?
<TFK>
Where "genome" is an int and a string of ~256 bytes.
<TFK>
I have a matrix of "cells", but they're all mutable, so I don't create new cells, only change their attributes.
<love-pingoo>
mmm
<love-pingoo>
and the memory keeps growing ?
<love-pingoo>
are you on 32 or 64 bits ?
<TFK>
Well, when I call Gc.major_full every 1e5 iterations, it grows really, really slowly, makes me suspect System Monitor is leading me astray.
<TFK>
64
<love-pingoo>
and if you don't call it ?
olleolleolle has joined #ocaml
<bluestorm>
TFK: i think you could/should make the code available (if you intend to open-source it eventually, of course)
<TFK>
And if I don't call it, memory grows pretty fast.
<love-pingoo>
there was a funny bug on 64bits, recently.. I think it only caused an initial silly huge consumption of memory, but let me check
<TFK>
bluestorm, I'm planning to (Nanopond is GPL anyway), I just want to iron it out first :-)
<TFK>
Another curious thing: when I changed space_overhead, full major got called on its own eventually, but didn't release any memory.
<TFK>
(at least, whatever create_alarm registered was called)
<TFK>
Well... besides performance, I want to understand the problem.
<bluestorm>
bogus argument :)
<TFK>
Understanding the problem is not important?
<bluestorm>
of course it is, but understanding it after a release makes no difference
<TFK>
after a release?
olleolleolle has quit []
sgnb has joined #ocaml
mattam has quit ["Lost terminal"]
mattam has joined #ocaml
ita|zzz is now known as ita
Linktim has quit [Read error: 104 (Connection reset by peer)]
Linktim has joined #ocaml
ofaurax has joined #ocaml
olleolleolle has joined #ocaml
coucou747 has joined #ocaml
TFK has quit ["Leaving"]
marmottine has joined #ocaml
love-pingoo has quit ["Connection reset by pear"]
coucou747 has quit ["bye ca veut dire tchao en anglais"]
jderque has quit ["zoo"]
olleolleolle has quit []
jlouis_ has joined #ocaml
ardor has joined #ocaml
<ardor>
hi guys
jlouis has quit [Read error: 110 (Connection timed out)]
jderque has joined #ocaml
LordMetroid has joined #ocaml
ita has quit [Remote closed the connection]
dwmw2_gone has joined #ocaml
linktim_ has joined #ocaml
olleolleolle has joined #ocaml
olleolleolle has quit []
Linktim has quit [Read error: 110 (Connection timed out)]
olleolleolle has joined #ocaml
linktim__ has joined #ocaml
linktim_ has quit [Read error: 110 (Connection timed out)]
linktim_ has joined #ocaml
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
pango_ has joined #ocaml
linktim__ has quit [Read error: 110 (Connection timed out)]
linktim_ has quit [Read error: 110 (Connection timed out)]
jderque has quit ["leaving"]
bongy has quit ["Leaving"]
robyonrails has joined #ocaml
pango has quit [Remote closed the connection]
Morphous has joined #ocaml
LordMetroid has quit ["Leaving"]
Amorphous has quit [Connection reset by peer]
jlouis has joined #ocaml
Morphous has quit [Read error: 110 (Connection timed out)]
waxblood_ has joined #ocaml
<waxblood_>
What's the ocaml function to parse and evaluate ocaml code?
<bluestorm>
there isn't
<thelema|away>
waxblood_: sorry, no can do.
thelema|away is now known as thelema
<bluestorm>
usually you can do without that kind of things
<bluestorm>
if you _really_ want something like that, have a look at MetaOCaml
det has joined #ocaml
<thelema>
the ocaml runtime doesn't include an ocaml interpreter/compiler
<bluestorm>
but most probably you're too used to dynamic scripting languages, and you use that kind of things where you could do differently (and, imho, better)
Amorphous has joined #ocaml
<waxblood_>
bluestorm: I like to do genetic programs, and I wanted to see if Ocaml can do that kind of things - I like its syntax and type-system
<bluestorm>
hm
<bluestorm>
you could do that, but it would be ugly
<waxblood_>
and with Metaocaml?
<bluestorm>
(basically, once you've a representation of an ocaml program, write that into a file, and then compile/execute it)
<bluestorm>
i don't know MetaOCaml enough
<bluestorm>
but i'm not sure
<bluestorm>
(i don't know MetaOCaml at all, actually)
<bluestorm>
but the compilation approach seems praticable
<bluestorm>
although maybe a bit too heavy for a "genetic" use
<bluestorm>
got to go, anyway
<thelema>
bluestorm: making your own simple language with an ocaml representation and a simple interpreter is very easy in OCaml - try that method of genetic programming
jlouis_ has quit [Read error: 110 (Connection timed out)]
<thelema>
1st google result on "ocaml genetic programming"
<Smerdyakov>
waxblood_, I think you have an understanding gap if you believe a language can't be used to implement genetic programming if it doesn't support loading of code from source.
<waxblood_>
thelema: results for "ocaml eval" or "ocaml repl" where less informative, so I got a little discouraged
<Smerdyakov>
waxblood_, again, if you think those were important Google searches to understand whether OCaml can be used for genetic programming, you have an understanding problem.
<thelema>
waxblood_: glad you checked here.
<thelema>
Smerdyakov: that's how it's done in other languages. he just didn't know.
<waxblood_>
exactly.
<ardor>
What do you guys think of F#
<Smerdyakov>
I have to hold my ground and say it's worth some rethinking if a person can't conceive of another way of doing genetic programming.
<waxblood_>
Smerdyakov, I wanted eval just to perform some little experiment with ocaml, genetic programming was a second goal
<Smerdyakov>
waxblood_, OK.
<thelema>
ardor: I approve of more people using ocaml-like programming styles. I haven't used it myself.
<ardor>
What IDE do you use for Ocaml ?
<thelema>
ardor: emacs
<Smerdyakov>
Almost all OCaml programmers use Emacs.
<waxblood_>
I'd check out cameleon, if it run on my Ubuntu Gutsy :(
<ardor>
does emacs do autocomplete?
jderque has joined #ocaml
<thelema>
ardor: alt-/ (or in emacspeak, M-/)
waxblood_ has quit ["Leaving"]
szell has joined #ocaml
thermoplyae has joined #ocaml
szell has quit [brown.freenode.net irc.freenode.net]
Snark_ has joined #ocaml
szell has joined #ocaml
Smerdyakov has quit ["BRB"]
Smerdyakov has joined #ocaml
Snrrrub__ has joined #ocaml
Snrrrub___ has joined #ocaml
LordMetroid has joined #ocaml
Snrrrub__ has quit [Read error: 110 (Connection timed out)]
Sapan has joined #ocaml
<Sapan>
anyone know of a way to convert from Unix.file_descr -> int ?
<rwmjones>
Sapan, Obj.magic :-)
<rwmjones>
they're the same thing
<Sapan>
rwmjones: i need to pass one to an external C function definition. Would Int_val () from C see the right value?
ttamttam has left #ocaml []
<rwmjones>
Sapan, no
<rwmjones>
erm, sorry yes
<rwmjones>
or would it
* rwmjones
checks
* Sapan
is checking as well
<rwmjones>
Sapan, yes it would work
<rwmjones>
Unix.file_descr is just an int
<rwmjones>
an OCaml int
<rwmjones>
so Int_val will work fine
<Sapan>
ok, thanks
<pango_>
on unixen only
ita has joined #ocaml
Smerdyakov has quit ["Leaving"]
Smerdyakov has joined #ocaml
Snark_ has quit ["Ex-Chat"]
Yoric[DT] has quit [Read error: 113 (No route to host)]
<bluestorm>
oh
<bluestorm>
i thought he specifically wanted to "genetically" create 'ocaml programs'
Snrrrub___ is now known as Snrrrub
jderque has quit ["leaving"]
jlouis_ has joined #ocaml
|Catch22| has joined #ocaml
Yoric[DT] has joined #ocaml
goalieca has joined #ocaml
jlouis has quit [Read error: 110 (Connection timed out)]
marmottine has quit [Remote closed the connection]
marmottine has joined #ocaml
<Yoric[DT]>
Does anyone know if there's a %identity-style primitive for applying a function to an argument ?
<bluestorm>
is that not just identity ?
Yoric_ has joined #ocaml
Yoric[DT] has quit [Nick collision from services.]
Yoric_ is now known as Yoric[DT]
<Yoric[DT]>
Back from X freeze
<ita>
Yoric[DT]: [22:21] <bluestorm> is that not just identity ?
<Yoric[DT]>
Just trying to check if there's anything better.
* Yoric[DT]
is still fighting with the performances of his exception library.
<Smerdyakov>
My goodness. A rare use of non-idiomatic English by Yoric, with "performances" in place of "performance"! ;)
<bluestorm>
:D
<Yoric[DT]>
Should I have written performance ?
<Yoric[DT]>
Or is that a pun related to acting ?
<Smerdyakov>
Yes, and also avoid spaces before question marks. :P
<Smerdyakov>
It's not a pun. "Performance" is never pluralized in the context of computer efficiency measurement.
<Yoric[DT]>
Thanks for the tips.
<ita>
no wonder your code is acting weird
<Yoric[DT]>
Somehow, being nicknamed Yoric, I tend to attract acting-related puns :)
<Smerdyakov>
But, seriously, your English rocks. You're French, right?
<Yoric[DT]>
I am.
<Smerdyakov>
These other clowns in here should take a lesson from you. :P
<Yoric[DT]>
And thanks.
* Yoric[DT]
starts to blush.
<bluestorm>
My goodness. A rare compliment from Smerdyakov.