<hcarty>
This is in the context of numeric.ml in pa-do
<hcarty>
The point is to allow Complex.(x.re) to act as x.Complex.re, without using pa_openin-like functionality which could potentially slow things down in some cases
comglz_ has quit [Client Quit]
pango_ has quit ["I shouldn't really be here - dircproxy 1.0.5"]
pango_ has joined #ocaml
Linktim_ has joined #ocaml
<bluestorm>
slow things down ?
<bluestorm>
(there is a "handy record notation" syntax extension wich do related and lovely things, you should have a look)
<bluestorm>
the code seems correct
<bluestorm>
but horribly ad-hoc and inelegant
code17 has quit [Remote closed the connection]
<hcarty>
bluestorm: Indeed. pa-do provides functions to do this in a cleaner manner
code17 has joined #ocaml
<hcarty>
"slow things down" -- for some (simple?) cases, using "Module.(something)" with openin in an expression is slower than using "something" directly. I'm guessing due to inlining or some kind of optimizations which don't work across module bounds?
<hcarty>
I wrote a simple benchmark for to test for this a while ago, I'm not sure if I still have it
<bluestorm>
i'd be interested
<bluestorm>
btw, i saw in the source that they included (and adapted) pa_openin source directly
<bluestorm>
i should suggest the to remove the useless temporary identifier
<hcarty>
bluestorm: I'll suggest that
Linktim has quit [Read error: 113 (No route to host)]
marmotine has quit [Read error: 110 (Connection timed out)]
coucou747 has quit [Read error: 110 (Connection timed out)]
coucou747 has joined #ocaml
thelema has joined #ocaml
<hcarty>
bluestorm: I can't find the benchmark I used, and an attempt to recreate them gave the opposite result :-)
<hcarty>
I'm on a 64bit system now, while I was a on a 32bit system before. I don't know if that makes any difference.
<bluestorm>
sounds a bit strange at least :p
<bluestorm>
hcarty: without further information, i think the saner idea is to use the open_in trick
<bluestorm>
if it really turned into a performance problem, an other possibility would be to replace every qualified name in the AST, effectively having the same effect as openin, but at camlp4 time
<bluestorm>
half-baked solution can only lead to inconsistencies (fear, inconsistency and doubt :-')
rwmjones has quit ["Closed connection"]
xavierbot has quit [Remote closed the connection]
xavierbot has joined #ocaml
<bluestorm>
(!);;
<xavierbot>
- : 'a ref -> 'a = <fun>
<coucou747>
Oo
<bluestorm>
the real deal.
<coucou747>
xavierbot> let rec bluestorm = " bluestorm ":: bluestorm;;
<xavierbot>
Characters 49-58:
<xavierbot>
xavierbot> let rec bluestorm = " bluestorm ":: bluestorm;;
<xavierbot>
^^^^^^^^^
<xavierbot>
Parse error: "in" expected after [binding] (in [expr])
<coucou747>
Oo
<coucou747>
xavierbot> let rec bluestorm = " bluestorm ":: bluestorm in bluestorm ;;
<xavierbot>
Characters 1-10:
<xavierbot>
xavierbot> let rec bluestorm = " bluestorm ":: bluestorm in bluestorm ;;
<bluestorm>
don't expect the bot to know that "xavierbot> " is not part of the source code
<bluestorm>
because it could be
<coucou747>
Oo
<coucou747>
ah ok
<bluestorm>
now we have an output problem
<coucou747>
it was a mass - HL test :)
<bluestorm>
hm
<bluestorm>
seems the output is actually correct
<flux>
0;;
<xavierbot>
- : int = 0
<flux>
right, it didn't die on that :)
<bluestorm>
the default toplevel print much more terms
<flux>
(should've remembered that the toplevel doesn't either)
<mbishop>
let x x y z = z x y in let x y = x (x y) in let x y = x (x y) in let x y = x (x y) in let x y = x (x y) in let x y = x (x y) in x;;
<xavierbot>
- : 'a ->
<xavierbot>
'b ->
<xavierbot>
(('c ->
<xavierbot>
(('d ->
<xavierbot>
(('e ->
<xavierbot>
(('f ->
<xavierbot>
(('g ->
<xavierbot>
(('h ->
<xavierbot>
(('i ->
<xavierbot>
(('j ->
<mbishop>
:P
<flux>
perhaps the limits could be shorter
<bluestorm>
or the per-line limit longer
<flux>
also a considerable amount of mistakes come from that the bot doesn't require a prefix
<flux>
# could be such a prefix, it would then be very similar to the toplevel :)
<bluestorm>
iirc there was a prefix before
<flux>
I was thinking requiring both prefix and suffix, has that been before?
<mfp>
bluestorm, hcarty: let module X = ... causes allocation unless it's a mere module alias
<mfp>
hence the possible openin overhead
<mfp>
a prefix for xavierbot seems a good idea, there are too many spurious ; ; on #ocaml
<bluestorm>
mfp: do you know what is allocated ? (iirc. in the openin case, the content of the module is "include Foo let bar = ...")
bacam has joined #ocaml
<mfp>
bluestorm: the module itself, so to speak. It then initializes a slot for the bar function.
<hcarty>
bluestorm: Very good point regarding just using openin. If a simple benchmark is giving such strange results, this probably counts as severe premature optimization
mwhitney has quit ["WeeChat 0.2.6"]
<mfp>
bluestorm: essentially, it's as if the module were a first class value: it is instantiated at run-time the same way normal modules are in their camlFoo__entry functions, using the heap instead of the data section.
<hcarty>
The transformation can be done with pa-do, so if something like that is needed later it can be implemented
<hcarty>
mfp: Thank you for the clarification
<hcarty>
I may bring up the idea to the pa-do folks just to see what they think
mwhitney has joined #ocaml
<hcarty>
bluestorm: Enabling openin (among other options) as a default action with Module.(...) syntax using pa-do is now possible with the latest bzr revision
<hcarty>
The pa-do developers are wonderfully responsive
Camarade_Tux_ has joined #ocaml
Camarade_Tux has quit [Read error: 110 (Connection timed out)]
Mr_Awesome has quit ["aunt jemima is the devil!"]
Camarade_Tux_ is now known as Camarade_Tux
coucou747 has quit ["bye ca veut dire tchao en anglais"]
<hcarty>
For this overly simplified case, the difference on my system is a little less than 50% for native code
<hcarty>
As in the slow version takes ~50% longer to run than the fast version
rwmjones has joined #ocaml
<mfp>
hcarty: it's irrealistic in that you allocate a closure per iteration
<hcarty>
mfp: But that is how opening Foo in Foo.(...) would work
<hcarty>
If you use a naive openin-like extension
<mfp>
ah, so this is M.(float_of_int i * 2.0)
<hcarty>
Yes
<mfp>
does pa_do allow M.begin .... end ?
<hcarty>
No, apparently not
<hcarty>
I just tried it with no luck
<mfp>
putting the for loop inside M.() would allow to minimize the module instantiation overhead
<mfp>
it seems that enabling "open in" with Foo.(...) is not a good idea in general, though
<mfp>
since Float.(....) is going to be one of the principal uses, any slowdown would be bad news
<hcarty>
mfp: Yes, pa-do currently supports it on a module-by-module basis by default
<hcarty>
Enabling openin as a default action for Foo.(...) only applies for modules with no overloading defined, and even then you have to specify that you want to enable this
<hcarty>
Adding OVERLOAD_OPENIN DEFAULT to a source file would enable openin for Foo.(...) but not Float.(...) for example. As I understand it at least.
<mfp>
hum the compiler should be smart enough to skip the module allocation + init in this case :-|
asma has quit [Read error: 110 (Connection timed out)]
guillem_ has joined #ocaml
<hcarty>
Given that it isn't at this time, camlp4 translations seem like a reasonable fix for now
<hcarty>
If the compiler does gain such optimizations then the result of the syntax translation could be simplified accordingly
hkBst has joined #ocaml
besiria has quit [Remote closed the connection]
<Yoric[DT]>
Yeah, I've noticed nice speed-ups with Camlp4-based inlinings.
rwmjones has quit ["Closed connection"]
lde has quit [Read error: 113 (No route to host)]
lde has joined #ocaml
lde has quit [Remote closed the connection]
code171 has joined #ocaml
<hcarty>
bluestorm: The "handy record notation" extension doesn't do what I want, if it's the extension I think it is