<gildor>
lets add the whole thing, CS in general is good
<maxote>
is metaocaml dead?
<mfp>
maxote: IIRC development was supposed to resume in fall 08
<gildor>
mfp: I am very impressed by your benchmark
fschwidom has joined #ocaml
<mfp>
owning Rails is not surprising (nor is there much merit in it), for me the surprise was that Ocsigen compares favorably to lighttpd + minimal FastCGI process written in C
<mfp>
well, not really "surprise"
<gildor>
do you have an idea if it will compare well with PHP + Apache ?
<maxote>
the fastest is a multithread C executable that listens the 80 port
<mfp>
gildor: oh, most likely --- when I googled for benchmarks some time ago, the PHP frameworks were given quite pathetic figures
<gildor>
mfp: ok, great
<mfp>
maxote: yes, it's going to be faster, but not by much. "hello world" essentially measures routing/dispatching overhead, and tells us Ocsigen doesn't suck at that.
<maxote>
s@C@C/C++
<gildor>
maxote: you will be suprise that OCaml can be REALLY very close to C
<maxote>
gildor, eye! the OCaml performance is worse if the multithread is enabled
<gildor>
the benchmark by mfp show that it has the same memory usage
<mfp>
so for anything beyond "hello world", we're playing the native code vs. native code game, and we know OCaml doesn't play badly at that. Ultimately, none of this matters much, of course, if the application is limited by the DB.
<mfp>
maxote: Ocsigen _is_ compiled with -thread
<gildor>
maxote: I have used ocaml + multiprocess to outperform a multithreaded C app
<gildor>
and it works very well
<mfp>
(it just doesn't use kernel threads, but rather lightweight threads)
<maxote>
i should use Route Load Balancing + Xen/NetBSD + multithread C/C++ executable that listens port 80
jeremiah has joined #ocaml
<gildor>
maxote: don't see your point, Route Load Balancing and Xen/NetBSD can apply to any app (whatever the programming language)
* Camarade_Tux
would like a wiki in ocaml, with dokuwiki-like features but in muuuuch faster
<mfp>
Everybody is fixating on the 5800 vs. 430 figures, which admittedly don't mean much. My message was rather "Standalone apps for trivial deployment, great. Yay Ocsigen doesn't suck at routing/dispatching! It's nice to be on the right side of the native / interpreted code divide because the extra speed gives you new opportunities."
<mfp>
it's been misunderstood as "Ocsigen stomps Rails yeah hello world is the ultimate real world application lolz"
<tsuyoshi>
yeah.. rails might be the slowest framework out there
<tsuyoshi>
beating fastcgi is pretty impressive though
<gildor>
tsuyoshi: I don't think it beats fastcgi
<tsuyoshi>
iirc it did beat fastcgi on a single core
red_eyes has joined #ocaml
<mfp>
I tried to make Lwt use epoll instead of select the other day for extra speed, takes a few dozen LoCs but haven't got it to run yet :|
<maxote>
fastcgi will have issues as memory leaking during long time, sessionless, ...
<mfp>
tsuyoshi: well I couldn't compare lighttpd with 1 FastCGI process to Ocsigen because it essentially bombed, it was just 5xx'ing all the time
red_eyes has left #ocaml []
<mfp>
so had to run it with max_procs > 1
<tsuyoshi>
so... oscigen won by default
<mfp>
per-core, the routing/dispatching overhead is roughly the same in Ocsigen and lighttpd + FastCGI (maybe slight advantage for Ocsigen, maybe not)
<tsuyoshi>
if you can hook it up to postgresql and then run multiple processes oscigen should be pretty fast on multiple cores too
<tsuyoshi>
or can you already run multiple oscigen processes?
<mfp>
yeah, standard load-balancing would work fine
<mfp>
I tried to run a couple Ocsigen servers behind nginx, perf didn't improve
<tsuyoshi>
nginx?
<mfp>
two reasons: nginx <-> Ocsigen overhead, and I'm running ab locally, so it also takes some CPU time (around 20% of one core IIRC)
<mfp>
nginx, the new trendy (small + fast) web server
<maxote>
in theory, the fastest is 1 user's session <-> 1 user's process on 1 core
<Camarade_Tux>
mfp, as far as I'm concerned, I was pleased to simply see ocsigen used in "real-world" and performing well :)
<mfp>
this isn't "real-world" though :)
<Camarade_Tux>
you were on reddit ;)
<tsuyoshi>
we don't yet have any high traffic sites running it
<Camarade_Tux>
btw, how did this redditing went compared to others ?
<maxote>
so, the fastest is N users's sessions <-> N users's process on N cores
jeremiah has quit [Read error: 104 (Connection reset by peer)]
<maxote>
processes
<mfp>
it's just a proof-of-concept for statically-linked Ocsigen servers+apps, and a personal itch of mine (the old Ruby sw. for eigenclass was dog slow)
<maxote>
i think that a persistent load balancer (with reliable backups of their buckets's info) is easier
<mfp>
Camarade_Tux: it generated a couple thousand visits to that page overall; 1K visits from programming.reddit, ~500 from news.ycombinator
<mfp>
the usual figures
<Camarade_Tux>
so less than I thought, I wonder how we could "force" a /. effect on an ocsigen site
<tsuyoshi>
put something that slashdot readers want to read on an ocsigen site
<mfp>
I got 2-3 times more visits in the prev entry (log processing on the T2K)
<tsuyoshi>
like nude photos of natalie portman or something
<Camarade_Tux>
tsuyoshi, yeah, I think that's still the best way unfortunately ;)
ikaros has quit [kornbluth.freenode.net irc.freenode.net]
vixey has quit [kornbluth.freenode.net irc.freenode.net]
Stefan_vK has quit [kornbluth.freenode.net irc.freenode.net]
Mr_Awesome has quit [kornbluth.freenode.net irc.freenode.net]
mikeX has quit [kornbluth.freenode.net irc.freenode.net]
bzzbzz has quit [kornbluth.freenode.net irc.freenode.net]
l_a_m has quit [kornbluth.freenode.net irc.freenode.net]
Jedai has quit [kornbluth.freenode.net irc.freenode.net]
mfp has quit [kornbluth.freenode.net irc.freenode.net]
erg has quit [kornbluth.freenode.net irc.freenode.net]
shortc|desk has quit [kornbluth.freenode.net irc.freenode.net]
<tsuyoshi>
seriously though.. if you really want to demonstrate the speed of ocaml.. make a program that morphs natalie portman's face and then hook it up to ocsigen
<tsuyoshi>
that would defintiely get some hits
Stefan_vK1 has joined #ocaml
ikaros has joined #ocaml
vixey has joined #ocaml
Stefan_vK has joined #ocaml
Mr_Awesome has joined #ocaml
mikeX has joined #ocaml
bzzbzz has joined #ocaml
l_a_m has joined #ocaml
Jedai has joined #ocaml
mfp has joined #ocaml
shortc|desk has joined #ocaml
erg has joined #ocaml
<Camarade_Tux>
the reason why I only check the programming reddit ;)
<Camarade_Tux>
tsuyoshi, and implement the morphing using obrowser ;)
Kerris4 has joined #ocaml
Kerris4 has left #ocaml []
<tsuyoshi>
hahah yeah
<tsuyoshi>
although that wouldn't stress ocsigen quite so much
<Camarade_Tux>
and would be quite slow
<Camarade_Tux>
or maybe you have a constant exchange between the browser and the server
schme has joined #ocaml
<mfp>
the OBrowser/Ocsigen guys said they wanted to make an ocaml plugin and leave the JS engine as a safety net, wonder if they have begun any work on that
<Camarade_Tux>
that reminds me we still need a study of who downvotes ocaml articles, maybe we can see which articles are upvoted when ocaml ones are downvoted, it'd be very hard to draw proper conclusions but on a large timeframe, that should be conclusive
jeremiah has joined #ocaml
<Camarade_Tux>
mfp, yeah, some security settings would prevent plugins plus some architectures are a pain
<Camarade_Tux>
plus npplugins completely suck
Kerris4 has joined #ocaml
Kerris4 has left #ocaml []
Associat0r has joined #ocaml
Stefan_vK has quit [Connection timed out]
jeremiah has quit [Read error: 104 (Connection reset by peer)]
Associat0r has quit [Connection timed out]
fschwidom has quit [Remote closed the connection]
ygrek has quit [Remote closed the connection]
marmotine has joined #ocaml
jeremiah has joined #ocaml
Associat0r has joined #ocaml
Yoric[DT] has joined #ocaml
ygrek has joined #ocaml
Associat0r has quit []
Associat0r has joined #ocaml
jeremiah has quit [Read error: 104 (Connection reset by peer)]
buluca has quit [Read error: 110 (Connection timed out)]
alexyk has joined #ocaml
alexyk_ has joined #ocaml
alexyk has quit [Read error: 60 (Operation timed out)]
ched has joined #ocaml
jeremiah has joined #ocaml
mikeX has left #ocaml []
_zack has joined #ocaml
Camarade_Tux has quit [Remote closed the connection]
Camarade_Tux has joined #ocaml
_zack has quit ["Leaving."]
jeremiah has quit [Read error: 104 (Connection reset by peer)]
jeremiah has joined #ocaml
ikaros has quit [Remote closed the connection]
alexyk_ has quit []
itewsh has joined #ocaml
alexyk has joined #ocaml
bluestorm has joined #ocaml
alexyk has quit [Read error: 110 (Connection timed out)]
<thelema>
bluestorm: any brilliant new camlp4 extensions lately?
<kig>
write me a parser for test generation :P
<mrvn>
I could use a parser for C99 code.
<mrvn>
or a c99 to ocaml compiler.
* Yoric[DT]
is still waiting for bluestorm to finalize his extensions for Batteries.
<mrvn>
What is that?
<thelema>
mrvn: batteries is an extended ocaml environment - better stdlib, better syntax
<thelema>
mrvn: you don't want to convert C99 to ocaml
<thelema>
or rather, why do you think you do?
<mrvn>
type safety, garbage collection and boundray checks
<thelema>
mrvn: except it'll be extremely difficult to take ocaml's error messages and fix the C99
<mrvn>
yeah, an interpreter would be best.
<thelema>
as to GC, aren't there already C environments that do such?
<bluestorm>
Yoric[DT]: i know, i've been less than reliable lately, i'll try to do that during the w.e.
<mrvn>
thelema: only conservative GCs which are inaccurate
<Yoric[DT]>
bluestorm: Happy New Year, by the way.
<thelema>
mrvn: it's worth spending a little while to learn the syntax - you'd have to learn the rest of the language to use it anyway.
<bluestorm>
(btw., has there been some 3.11-for-godi progress lately ?)
* Yoric[DT]
hasn't worked on that front yet.
<mrvn>
thelema: the point would be to catch errors in existing C code.
ofaurax has joined #ocaml
<thelema>
mrvn: such a conversion system would likely draw the net too fine, and catch things that aren't errors.
<thelema>
in C, assumptions about values (types) can be temporarily ... not followed. And the program can still work perfectly.
<mrvn>
thelema: compiler defined behaviour.
<mrvn>
I think what you mean is the most frequently used void *data = i;
* Yoric[DT]
wouldn't take the chance of compiling C99 to OCaml.
<mrvn>
Would be nice though to track that is now an int and error if it gets used as pointer.
<thelema>
that's part of it. Also, everything in C is nullable... pointer arithmetic, etc.
<thelema>
you'd do better writing some static analysis tools designed for C99
<thelema>
Now that you could do in ocaml.
<mrvn>
thelema: a pointer is only valid inside the allocated chunk of memory and the value one beyond it for assignment only.
<mrvn>
type pointer = { start; length; mutable pos; }
<thelema>
inside any allocated chunk of memory
<mrvn>
thelema: no. Only the one it was assigned.
<mrvn>
If you have 2 allocated regions next to each other and a pointer overflows from one into the other that works in real live but is still wrong.
<Yoric[DT]>
Well, there's an OCaml-based static analysis toolbox for C.
<mrvn>
static analysis doesn't find much. I want dynamic.
<mrvn>
but they should have a parser.
<Yoric[DT]>
CIL is a good parser for C.
<thelema>
dynamic analysis = runtime checks, no?
<Yoric[DT]>
Well, it does more than parsing, it also simplifies C to a smaller language.
<mrvn>
thelema: yes. I want an interpreter that works directly on the source form. So when it finds an error it can point directly at the file/line.
<thelema>
the line that a runtie check fails isn't necessarily the line that needs to be fixed, of course.
<mrvn>
thelema: the I want to hit the "up" button to get the calling function.
<mrvn>
And no optimized out variables and such like you have in gdb all the time.
<thelema>
that is one advantage of ocaml in terms of debugging - if your source code says to do xyz, the compiler prouces code to do xyz. very little optimization there.
<mrvn>
yeah, I noticed that. Even if you tell it to do stupid things it will do it.
<mrvn>
Would be nice though if the compiler could detect common subexpressions better.
<mrvn>
On that note. Is there any way to declare an argument const?
<thelema>
mrvn: huh? all arguments are const, except the ones that aren't. :)
<thelema>
everything's immutable except the things that are specifically mutable: arrays, refs, mutable record cells
<mrvn>
type foo = { mutable x : int } let inc foo = foo.x <- foo.x + 1 let get (foo : const foo) = foo.x
<thelema>
nope, no provision in the language for that.
<mrvn>
The const would say the argument will not be altered even though it is mutable. That way the compiler could detect a "get foo" as common subexpression and optimize it out.
<thelema>
I guess you could define type foo_const = ... no, you'd collide the record namespace
<mrvn>
thelema: and you couldn't pass a foo to it.
<thelema>
I don't know if the current inlining code suffices for that job.
<mrvn>
thelema: the function could be any size and still have const args.
<thelema>
an identity function to convert between the types...
<mrvn>
thelema: you can't convert a foo_const to foo.
<thelema>
why not?
<mrvn>
Because it is const. you would violate that.
<Yoric[DT]>
Well, there's certainly an awful Obj.magic way of doing const but I wouldn't try.
<thelema>
In general, if you want the common subexpression pulled out, do it yourself.
<thelema>
it's not that hard.
<mrvn>
Yoric[DT]: yeah. But I doubt that would help for the optimized.
<mrvn>
optimizer
<kig>
optimizing preprocessor
<mrvn>
thelema: it would only be common if the function is const.
<mrvn>
thelema: I can't know that "String.length str" is a common subexpression unless I read the source for String. (well, trivial example but you get my drift)
<thelema>
well, what you want is the idea of pure functions, I think.
<mrvn>
might be. In c++ the const keyword is used.
<thelema>
in the functional world, the concept of a "pure" function is one with no side-effects
<thelema>
const isn't enough for common subexpression optimization - there could be IO involved that'd need to be duplicated.
<mrvn>
The function has to be marked as const for it to be pure.
<mrvn>
well, it isn't exactly the same. but the closest c++ has
<thelema>
but const arguments aren't sufficient
pango has quit [Remote closed the connection]
<mrvn>
no. But consider f x; g x; f x;
<thelema>
well, that whole line assumes side-effects everywhere.
<mrvn>
With f being pure and g : const foo -> unit the f x is a common subexpression.
<thelema>
if f is pure, f x; is a no-op
<mrvn>
if f x then ...; g x; if f x then ....
vixey has quit [Remote closed the connection]
<kig>
iirc the compiler internally keeps track of the purity of the code, maybe you could hook something up to that
<thelema>
okay, yes you'd need to know that g doesn't modify x in order to reduce to let v = f x in if v then ...; g x; if v then ...
<mrvn>
Now I have to manualy check that g x does not change x and that f is pure and write let t = f x in if t then ...; g x; if t then ...
<thelema>
but memoization fixes that very well too.
<mrvn>
thelema: memoization?
<mfp>
kig: it does? so we've had a primitive effect system all the time and didn't know it?
<thelema>
to solve recursive problems, it's useful to "remember" the results of past application
<thelema>
correct - memoizing a non-pure function would change the meaning of that function.
<mrvn>
But just knowledge about constness and purity would be way easier than memoization. No need to setup caching and such.
<mfp>
huh 'a pure vs. 'a, with subtyping ('a pure <: 'a), whether 'a pure or 'a = inferred
_zack has joined #ocaml
<mrvn>
mfp: With classes you can manually do that.
jeremiah has quit [Read error: 104 (Connection reset by peer)]
<thelema>
mrvn: knowledge about constness would have to be worst case, and memoization handles just what is.
<thelema>
if it's possible in any way for the value of x to change between the two calls to f, common subexpression fails
<thelema>
whereas if f almost always is the same in the two, memoization wins.
<mrvn>
thelema: the comparison of the args could be more expensive than the function itself.
<mrvn>
or even impossible
<thelema>
yes, this is where ocaml loses. When you tell it to make a function, it makes the function. It's possible to use global optimization techniques to find just the right amount of inlining so that certain optimizations are possible. on the other hand, function calls are really cheap, so ocaml often doesn't do as much inling as people want.
<thelema>
which contributes to ocaml being fast in the common case, while not being super-optimizing enough in certain benchmark cases.
<mrvn>
yeah. benchmarks mostly win on optimizations while ocaml wins on better code.
<thelema>
To get
<thelema>
uber performance out of ocaml, you can't use as high level of abstractions as you might want
jlouis has quit [Remote closed the connection]
vixey has joined #ocaml
itewsh has quit ["There are only 10 kinds of people: those who understand binary and those who don't"]
<thelema>
but it'll do plenty well even with really high level abstractions.
jlouis has joined #ocaml
<thelema>
(and not flattening the abstractions)
jeremiah has joined #ocaml
<mrvn>
hmm, what trick can one use to make sure Unix.file_descr gets closed. Currently I have a close on every place that raises an exception.
<kig>
wrap it
<kig>
withUnixFile filename (fun f -> do stuff)
<mrvn>
let wrapper x = let fd = ... in try f x fd with x -> Unix.close fd; raise x?
<kig>
yeah, try let rv = f x fd; Unix.close fd; rv with x -> Unix.close fd; raise x
<bluestorm>
kig: this won't "make sure"
<bluestorm>
hm
jeremiah has quit [Read error: 104 (Connection reset by peer)]
<kig>
what's "make sure"
<bluestorm>
actually it makes sure the fd is closed
<kig>
set close_on_exec and exec "cat"
<kig>
superior program
<thelema>
mrvn: there's only so much you can do, even in ocaml, but the wrapping method is appropriate for most people.
<bluestorm>
i meant that you can still have unsafe references to an old handle
<mrvn>
sure. you can always have that.
<thelema>
bluestorm: an evil programmer can break the wrapper, yes.
<mrvn>
I'm tempted to write a new Unix module that uses _finalize to close the fd if it is still open.
<bluestorm>
(for classes of mine i've been implementing a compiler for a tiny functional subset of caml, and i must say it's a very interesting experience; you also get to think of things like that)
<bluestorm>
mrvn: is _finalize reliable ?
<mrvn>
bluestorm: nope. Doesn't get called on program termination. But then unix closes the fd anyway.
<mrvn>
Also you never know WHEN it gets called.
<thelema>
mrvn: that's the thing about GC. you give up some control for lots of convenience
<thelema>
(and some correctness, usually)
<mrvn>
So I would create MyUnix.close and in _finalize check that fd is -1 and close it otherwise.
ikaros has joined #ocaml
<bluestorm>
btw
<bluestorm>
does anyone know of the open-source-LLVM-compiler of jdh has materialized out of thin air somewhere ?
<bluestorm>
i've been interested in a ocaml LLVM usage example recently, and haven't found a trace of his code
<thelema>
bluestorm: I think he's holding the code close until he's ready
<bluestorm>
not a trust-building decision
jeremiah has joined #ocaml
<thelema>
his problem is that he teases the community with promises. I don't disagree with releasing something that works, but he shouldn't taunt us before then.
^authentic has joined #ocaml
vixey has quit [Remote closed the connection]
hsuh has joined #ocaml
_zack has quit ["Leaving."]
authentic has quit [Read error: 110 (Connection timed out)]
^authentic is now known as authentic
PierreN has joined #ocaml
<PierreN>
hi
<thelema>
hi
<PierreN>
i'm trying to learn ocaml under a linux system (debian). Since I didn't find any specially valuable editor for ocaml, i'm trying to configure vim to use ocaml with it. coloration/syntaxe is fine. but for compilation I don't get it.
<bluestorm>
vim or emacs will be just fine
<schme>
PierreN: It seems to me that emacs has an interaction mode.
<bluestorm>
but they're editors, not compilers, you should use a shell for that (integrated into your editor or not)
<bluestorm>
PierreN: if you have a single ml file just do "ocaml foo.ml" in the command line
<bluestorm>
or, if you want to produce an executable, "ocamlc foo.ml -o foo"
<PierreN>
I have strings in a script, each one corresponding to an ocaml instruction. what i would like is to be able to launch the ocaml interpreter with a single instruction, then to be able to send a new one whenever i want without closing the interpreter. do you kno
<PierreN>
w how please ?
<thelema>
emacs
<thelema>
or copy/paste between two xterms
<PierreN>
bluestorm: the problem is if I have "1+1;;" in my .ml file `ocaml file.ml` doesn't print `2`
<bluestorm>
"ocaml" is the ocaml toplevel
<bluestorm>
use "ocaml" alone in your directory, then #use "myfile.ml"
<bluestorm>
(you have to type the # yourself, it's a toplevel directive)
<PierreN>
hum i didn't know that thanks
<PierreN>
it should be pretty easy now
<bluestorm>
emacs provide an interaction mode that can do that for you (you type in the editor, then send to current phrase to the toplevel in a few keystrokes), but i don't know for vim
<bluestorm>
(if you have no strong preference for one or the other i suggest you try emacs + tuareg-mode, it's quite nice)
<PierreN>
i don't like emacs :(
<bluestorm>
ah
<bluestorm>
and if you use the toplevel in a simple shell
Camarade_Tux has quit [Read error: 110 (Connection timed out)]
<bluestorm>
you should absolutely try ledit or rlwrap
<bluestorm>
wich add line-editing capabilities
<bluestorm>
just install rlwrap (should have a debian package) and try "rlwrap ocaml" (or use an alias ocaml='rlwrap ocaml')
Camarade_Tux has joined #ocaml
alexyk has joined #ocaml
<PierreN>
bluestorm: yeah that s slightly better thanks
munificent has joined #ocaml
munificent has left #ocaml []
alexyk has quit []
alexyk has joined #ocaml
jonasb has joined #ocaml
jonasb has left #ocaml []
Camarade_Tux_ has joined #ocaml
<Camarade_Tux_>
afaik there *should* be an issue of the "ocaml journal" with a first try at ocaml+llvm
Camarade_Tux has quit [Read error: 110 (Connection timed out)]
alexyk has quit [Connection timed out]
Camarade_Tux_ is now known as Camarade_Tux
<thelema>
Yoric[DT]: I like the new documentation for batteries
<Yoric[DT]>
:)
buzz0r_ has joined #ocaml
buzz0r__ has joined #ocaml
sporkmonger has joined #ocaml
<mfp>
thelema: new docs? are those the "API reference" on batteries.forge.ocamlcore.org/? (they look no diff from the way I remembered them)
<thelema>
I guess that hasn't been updated, if they look the same.
<thelema>
the current code generates a topic-oriented index on the left
<thelema>
also current API is flattened (no heirarchy of modules), so different index was needed
buzz0r_ has quit [Read error: 113 (No route to host)]
sporkmonger has quit []
ofaurax has quit ["Leaving"]
* thelema
uploads the current docs
Stefan_vK has joined #ocaml
ikaros has quit [kornbluth.freenode.net irc.freenode.net]
Stefan_vK1 has quit [kornbluth.freenode.net irc.freenode.net]
Jedai has quit [kornbluth.freenode.net irc.freenode.net]
erg has quit [kornbluth.freenode.net irc.freenode.net]
Mr_Awesome has quit [kornbluth.freenode.net irc.freenode.net]
shortc|desk has quit [kornbluth.freenode.net irc.freenode.net]
bzzbzz has quit [kornbluth.freenode.net irc.freenode.net]
mfp has quit [kornbluth.freenode.net irc.freenode.net]
l_a_m has quit [kornbluth.freenode.net irc.freenode.net]
<thelema>
any thoughts on making Num.t the default numeric type of batteries?
Demitar has quit [Remote closed the connection]
ikaros has joined #ocaml
Mr_Awesome has joined #ocaml
bzzbzz has joined #ocaml
l_a_m has joined #ocaml
Jedai has joined #ocaml
mfp has joined #ocaml
shortc|desk has joined #ocaml
erg has joined #ocaml
<thelema>
grr, forge.ocamlcore.org's shell doesn't have [mv]
<Yoric[DT]>
thelema: Num.t?
<Yoric[DT]>
Looks a tad violent for me.
<thelema>
well, Num.num
<thelema>
violent/
<thelema>
?
<Yoric[DT]>
heavyweight
<thelema>
yes, it is heavyweight, but why not encourage the use of the numerical tower when possible?
<mfp>
I've lost some context, but let me guess... thelema is talking about turning all integer literals into Num.num?
<thelema>
any thoughts on making Num.t the default numeric type of batteries?
<thelema>
when using ints, it's just an extra box, and some checking so that you don't overflow accidentally, but get real math instead
<thelema>
and for floats, I dunno the difference in performance, but it's probably incidental for most uses
<mrvn>
thelema: that makes it quite a bit slower
<mrvn>
like factor 10 easily.
<mfp>
hmm I can think of far more cases where I wanted int (for speed) than those where I needed Num.num
<Yoric[DT]>
Well, having one universal type, as in Haskell, would be nice.
<mfp>
iow., I rarely use Num.num and int is perfectly good most of the time, the opposite not being true
<thelema>
well, because of ocaml's operators, people are encouraged to use int and penalized for non-int math
<thelema>
(okay, "penalized" is a bit dramatic)
<mfp>
that's what pa_do solves
<thelema>
if you know about it.
<thelema>
and if the module you're [do]ing overrides (+), (-), (*), (/)
<mrvn>
thelema: then you know about it
<mfp>
IIRC it's actually add, sub, mul, div
<mfp>
(pa_do does (+) -> M.add, etc.)
<thelema>
really?
<thelema>
I didn't realize
<thelema>
of course we'd still have to handle literals as well.
<mfp>
yup, of/to_int, of_string, etc.
<mfp>
I mean, pa_do *does* handle literals & the module needs to have of_int... for that to work, IIRC
<thelema>
well, to do floats right, we'd have to pass the literal string into a conversion function, to avoid the float errors
<mfp>
Big_int.( 23 ** 567 mod 45 + "123456789123456789123456789") <- 1st example on pa-do.forge.ocamlcore.org/
<Camarade_Tux>
I made a quick benchmark : 1+1 done max_int+1 times, for ints, floats and Num.t
<Camarade_Tux>
int : 1.292080
<Camarade_Tux>
float : 6.256391
<Camarade_Tux>
num int : 16.225014
<Camarade_Tux>
well, s/num int/num
<mfp>
Camarade_Tux: to which extent did you unroll that loop? :)
<thelema>
okay, pa-do goes on the batteries todo list
<mfp>
AFAIK it was already :), but ask bluestorm
<Camarade_Tux>
mfp, the most simple thing : for i = 0 to max_int do ignore (1+1); done
* thelema
didn't find it there
<mfp>
then you probably want to unroll it a bit, otherwise you're also measuring the index arith
<mfp>
so int is probably 2X faster than shown in the above numbers
<mfp>
thelema: the unwritten one, I suppose. This is not the first time we talk about pa_do, and IIRC bluestorm OK'ed it some time ago.
* thelema
puts it on the written one.
<Camarade_Tux>
hmm, I added the timing for an empty loop and noticed I had made a typo : the correct time for num is about 9.824614 (it included the time for float too)
<Camarade_Tux>
and the () loop took as long as the ignore(1+1) one
<bluestorm>
mfp: yes i did
<bluestorm>
but you should probably do (or at least start) any integration work you think necessary :]
<thelema>
bluestorm: "you" = me?
<mfp>
surely "you" = you }:-)
<olegfink>
"the best thing about me, is that there are so many me's"
<olegfink>
can anyone comment on ocaml vs. arm eabi, or maybe just arm?
<olegfink>
i.e. what to expect and what is the most fashionable way to crosscompile today?
ygrek has quit [Remote closed the connection]
Snark has quit [Read error: 60 (Operation timed out)]
Waleee has joined #ocaml
buzz0r__ has quit [Read error: 113 (No route to host)]
marmotine has quit [Connection timed out]
Amorphous has quit [Read error: 145 (Connection timed out)]
marmotine has joined #ocaml
Amorphous has joined #ocaml
thelema has quit [Read error: 110 (Connection timed out)]