Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
sepp2k has joined #ocaml
<flux>
does the actual number matter, or is it just a performance-related?
NingaLeaf has quit [Quit: Leaving.]
thomasga has joined #ocaml
madroach has quit [Read error: Connection reset by peer]
madroach has joined #ocaml
obadz has joined #ocaml
<mfp>
flux: it does matter, it forces a full major heap scan every 500 regexp allocations. The rationale being that having more than 50KB worth of unreclaimed regexps (with each estimated at 100 bytes) is too costly.
<mfp>
now, picture the effect of that when you do e.g. Pcre.qreplace ~pat: a few thousand times, and you have a major heap in the hundreds of MBs :)
_andre has joined #ocaml
obadz has quit [Ping timeout: 250 seconds]
<flux>
oh it's the ocaml GC, I was thinking the comment referred to some internal GC pcre does..
<mfp>
right, you couldn't possibly imagine the 50 KB comment could refer to OCaml's GC :-))
<ely-se>
if it's in JS, be sure to put the comment *outside* the function body
<ely-se>
otherwise V8 won't inline the function due to its size
thomasga has quit [Quit: Leaving.]
Anarchos has joined #ocaml
tennix has quit [Ping timeout: 246 seconds]
<flux>
:-)
<ely-se>
I wish I were kidding :(
<mfp>
wow so v8 uses textual size as a proxy for function size, which means we're back to single-letter variable names if we want inlining?
<mfp>
s/function/code/
<mfp>
what will be next, introducing a goto primitive and asking that we forgo structured programming?
<ely-se>
I wish JS had goto.
<ely-se>
It would make code generation easier.
rgrinberg has joined #ocaml
<ely-se>
jmp
<Anarchos>
40 000 goto in linux source code : search "goto site:lxr.free-electrons.com/source"
<ggole>
goto does make compiler construction a bit more complicated
rgrinberg has quit [Ping timeout: 244 seconds]
lobo has joined #ocaml
<ely-se>
In the source language, yes.
<ely-se>
In the target language, no.
<ggole>
Various transformations are simpler on structured CFGs.
keen__________ has joined #ocaml
<ggole>
Starting with the ubiquitous SSA construction.
<ely-se>
SSA deals with gotos just fine.
keen_________ has quit [Ping timeout: 245 seconds]
<ggole>
The algorithm for constructing SSA form is simpler for structured programs.
<ely-se>
Not any different from a branch where the condition is a constant and both branches are the same basic block
<ely-se>
Yes, that's true, but the SSA representation itself doesn't care.
<ggole>
So what? Simpler algorithms, simpler compiler.
<ggole>
Go read the literature on the JVM compilers, they all take shortcuts that are justified by Java never producing unstructured byte code
<ggole>
While goto is not too expensive to support if there is a meaningful advantage, there is a cost.
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
BitPuffin has joined #ocaml
NingaLeaf has joined #ocaml
ryanartecona has joined #ocaml
zpe_ has joined #ocaml
zpe has quit [Ping timeout: 260 seconds]
NingaLeaf has quit [Quit: Leaving.]
paradoja has joined #ocaml
maarekj has joined #ocaml
AltGr has left #ocaml [#ocaml]
demonimin has quit [Ping timeout: 250 seconds]
maarekj has quit [Client Quit]
zpe has joined #ocaml
tmtwd has joined #ocaml
zpe_ has quit [Ping timeout: 245 seconds]
tmtwd has quit [Ping timeout: 240 seconds]
paradoja has quit [Ping timeout: 272 seconds]
abbe has quit [*.net *.split]
averell has quit [*.net *.split]
abbe has joined #ocaml
ryanartecona has quit [Ping timeout: 240 seconds]
grouzen has joined #ocaml
yomimono has quit [Ping timeout: 250 seconds]
thomasga has joined #ocaml
yomimono has joined #ocaml
paradoja has joined #ocaml
thomasga has quit [Quit: Leaving.]
rgrinberg has joined #ocaml
AlexRussia_ has joined #ocaml
thomasga has joined #ocaml
demonimin has joined #ocaml
Haudegen has quit [Remote host closed the connection]
kushal has joined #ocaml
kushal has quit [Changing host]
kushal has joined #ocaml
Sorella has quit [Quit: Connection closed for inactivity]
Haudegen has joined #ocaml
Haudegen has quit [Ping timeout: 245 seconds]
NingaLeaf has joined #ocaml
zpe has quit [Read error: Connection reset by peer]
Haudegen has joined #ocaml
ely-se has quit [Quit: leaving]
ely-se has joined #ocaml
paradoja has quit [Ping timeout: 246 seconds]
Anarchos has joined #ocaml
zpe has joined #ocaml
martintrojer has quit [Max SendQ exceeded]
martintrojer has joined #ocaml
ollehar has joined #ocaml
martintrojer has quit [Max SendQ exceeded]
martintrojer has joined #ocaml
schoppenhauer has joined #ocaml
jeffmo has joined #ocaml
<schoppenhauer>
hello. is it possible with ocaml to build something like c
<schoppenhauer>
++ type specializers?
<schoppenhauer>
(I currently use Coq to extract stuff to ocaml, and I have some quite long boolean lists, which I would like to optimize for space)
<schoppenhauer>
(that is, I need to have a different implementation for bool list than for other lists)
<Drup>
No you can't
thomasga has quit [Quit: Leaving.]
<schoppenhauer>
how about something like typeclasses/modules?
ollehar1 has joined #ocaml
ollehar has quit [Ping timeout: 272 seconds]
<schoppenhauer>
hm. is there something like sizeof(...) then?
<Drup>
you could do things based on first class modules
ely-se has quit [Quit: leaving]
<schoppenhauer>
Drup: hm. could you help me a little more, I am an absolute beginner with ocaml.
ollehar1 has quit [Ping timeout: 244 seconds]
<schoppenhauer>
Drup: can a module have a type parameter?
<schoppenhauer>
Drup: and can I match on it?
<Drup>
heh, Not really. To be honest, I'm not sure you should try to do this if you are an absolute beginner. Do you really need to optimize the output code of Coq that much ?
<Drup>
couldn't you change the representation at the Coq level instead ? That sounds like a better idea
ely-se has joined #ocaml
<schoppenhauer>
Well, I could write an extraction mechanism to C++ as well. But for the moment, specifically for testing, it would be better to have type specializers.
<schoppenhauer>
so far, I extracted to haskell. in that case, it did not matter, because it created the boolean list lazily and consumed it immediately.
thomasga has joined #ocaml
<Drup>
but if it's very long, you should probably not create a list of booleans to begin with, it's not the right data structure ..
paradoja has joined #ocaml
<schoppenhauer>
I actually don't want to discuss my design choices (because that would be too complex now). Just looking for a possibility.
darkf has quit [Quit: Leaving]
Guest38 has joined #ocaml
Guest38 has quit [Client Quit]
Guest38 has joined #ocaml
<schoppenhauer>
hm. is there a possibility of adding runtime type information?
<noze>
not that was what i meant with reasonable :]
<noze>
is there a reason not to release it as is?
<Drup>
Need to triage the bug and I didn't took the time
<Drup>
bugs*
thomasga has quit [Quit: Leaving.]
pyx has joined #ocaml
pyx has quit [Client Quit]
thomasga has joined #ocaml
paradoja has quit [Ping timeout: 240 seconds]
ollehar has joined #ocaml
noze has quit [Ping timeout: 256 seconds]
tmtwd has joined #ocaml
dsheets has quit [Ping timeout: 240 seconds]
tmtwd has quit [Ping timeout: 260 seconds]
freling1 has joined #ocaml
freling1 has left #ocaml [#ocaml]
BitPuffin has quit [Ping timeout: 260 seconds]
ygrek has joined #ocaml
thomasga has quit [Ping timeout: 246 seconds]
rgrinberg has quit [Ping timeout: 256 seconds]
rgrinberg has joined #ocaml
ollehar has quit [Ping timeout: 250 seconds]
Haudegen has quit [Ping timeout: 246 seconds]
shinnya has joined #ocaml
freling1 has joined #ocaml
Haudegen has joined #ocaml
ryanartecona has joined #ocaml
ollehar has joined #ocaml
MrScout has joined #ocaml
systmkor has quit [Ping timeout: 272 seconds]
<ollehar>
do generational and incremental gc have the same read/write barriers?
<ollehar>
if yes, then it would make no sense to get rid of one of those for optimization reasons.
<ggole>
Incremental is orthogonal to generational
rgrinberg has quit [Ping timeout: 265 seconds]
<ollehar>
ggole: even with regard to read/write barriers?
<ollehar>
In my case, would it speed up the OCaml GC to get rid of the incremental part?
<ggole>
Er, no
<ggole>
You'd just get worse latencies
<ollehar>
Yes, of course, there would be pauses.
<ollehar>
But would the "general" performance be better? In total.
<ggole>
Hmm, I don't *think* there is much of a cost to doing the work incrementally: but that could be wrong.
<ollehar>
Further science needed, then. :)
tmtwd has joined #ocaml
<ggole>
There's no particular bearing on write barriers that I'm aware of, though
<ollehar>
Just hoping there's an "easy" way to switch the feature off...
<ollehar>
Ok.
<ggole>
I think that the only effect of the barrier is to make sure every path from the major to minor heap exists in the remembered set
<ollehar>
Yeah.
<ollehar>
Just thinking if generational and incremental used the same barriers.
systmkor has joined #ocaml
<ollehar>
Then you might as well keep both.
<ollehar>
But why would you need read barrier for that...
<ollehar>
Googling...
<ggole>
Do you mean concurrent?
rgrinberg has joined #ocaml
<ollehar>
No.
<ggole>
Then I don't understand the question.
<ollehar>
The case with incremental gc is that you have to check each write to see if there any new paths between the heaps.
<ollehar>
That's called write barrier.
<ollehar>
Maybe you know that.
<ggole>
I don't think we are understanding "incremental gc" in the same way
<ollehar>
Really? The major heap gets marked in steps?
<ggole>
Incremental just means that not all sweeping/freeing work is done in one collection
<ggole>
It's done in slices
<ollehar>
Right.
<ggole>
This doesn't really have anything to do with barriers.
<ollehar>
But you need a write barrier for that, to check for changes _between_ the slices.
<ggole>
(At least, in the current OCaml design.)
<ollehar>
*between the mark phases
<ggole>
Hmm, perhaps I remember the details wrong
<ollehar>
Since the heap changes between the mark phases, you need to check for those changes, but only if you write to the heap object.
<ollehar>
This causes a minor slowdown to the overall collection, but you get better "real-time" performance/shorter pauses.
<ollehar>
BUT, since I need this for PHP, I don't care about the pauses.
<ollehar>
That's why I was thinking, maybe I can do without it for a better overall performance.
<ollehar>
But if generational GC needs write barriers anyway...
<ggole>
I don't think I did remember it wrong. The write barrier only exists to collect major->minor edges in the remembered set.
<ollehar>
How is that different from what I said? :)
<ggole>
I think you are confusing the major/minor distinction with incremental slices.
tmtwd has quit [Ping timeout: 240 seconds]
kushal has quit [Ping timeout: 244 seconds]
<ollehar>
Well, even if you only have one heap, you still need write barriers for incremental gc, because of new relations that can appear between the partial markings.
<ollehar>
Maybe I should just read up more. :)
tmtwd has joined #ocaml
<ggole>
I don't think that writes can change the colour of an object, so why would you need a barrier?
<ggole>
Maybe I'm wrong. It's been a while since I looked at the details.
<ollehar>
Yeah, I've only been reading about this for a week, so. :)
<ollehar>
If you have two objects, A and B, that don't reference each other. Then you mark B as garbage and continue the program. Then A references B with A->var = B. Then B has to change colour?
<ollehar>
Otherwise it would be collected.
<ggole>
If B is garbage, it cannot be referenced by A.
<ggole>
(Because garbage is what isn't referenced by anything.)
<ollehar>
Yes, it _wasn't_ referenced in the first marking. But then the marking stopped, and B got referenced again.
<ollehar>
Wait, you mean B fell out of scope?
<ollehar>
Hm.
tane has joined #ocaml
tennix has joined #ocaml
ryanartecona has quit [Quit: ryanartecona]
tmtwd has quit [Ping timeout: 245 seconds]
tennix has quit [Ping timeout: 256 seconds]
shinnya has quit [Ping timeout: 245 seconds]
slash^ has joined #ocaml
sepp2k has quit [Quit: Leaving.]
sh0t has joined #ocaml
kakadu has joined #ocaml
izaak has joined #ocaml
izaak has quit [Quit: izaak]
mea-culp` has joined #ocaml
tmtwd has joined #ocaml
mea-culp` is now known as mea-culpa`
mea-culpa has quit [Ping timeout: 272 seconds]
AlexRussia_ has quit [Ping timeout: 246 seconds]
zpe has joined #ocaml
mea-culpa` is now known as mea-culpa
zpe has quit [Remote host closed the connection]
izaak has joined #ocaml
zpe has joined #ocaml
dsheets has joined #ocaml
zpe has quit [Ping timeout: 245 seconds]
<Algebr>
Can oasis generate a make target that is like a style linter? does such a tool even exist?
ggole has quit []
shinnya has joined #ocaml
slash^ has quit [Read error: Connection reset by peer]
ollehar has quit [Ping timeout: 272 seconds]
Haudegen has quit [Ping timeout: 250 seconds]
_andre has quit [Quit: leaving]
rgrinberg has quit [Ping timeout: 240 seconds]
izaak has quit [Quit: izaak]
sh0t has quit [Ping timeout: 260 seconds]
izaak has joined #ocaml
Haudegen has joined #ocaml
izaak has quit [Ping timeout: 244 seconds]
NingaLeaf has quit [Quit: Leaving]
napping has joined #ocaml
<MercurialAlchemi>
grmbl
<MercurialAlchemi>
I wish ocaml had a debugging story
<flux>
printf, man, printf!
<napping>
Can the standard libraries Random be used with threads?
<MercurialAlchemi>
printf + ncurses = bang
<flux>
it is a bit sad that ocamldebug's main purpose is to exist so it's possible to say ocaml has a debugger :P
<napping>
I only see get_state and set_state for maintaining independent generators - aren't threads preemptive enough you might switch right after trying to set_state?
<flux>
napping, use Random.State
<flux>
napping, it has Random functions that explicitly take the state as a parameter