Ched- has quit [Read error: 110 (Connection timed out)]
Ched- has joined #ocaml
rhar has quit [Read error: 110 (Connection timed out)]
hsuh has joined #ocaml
hsuh has left #ocaml []
rhar has joined #ocaml
rhar has quit [Read error: 54 (Connection reset by peer)]
yziquel has quit [Read error: 104 (Connection reset by peer)]
dibblego has joined #ocaml
jeddhaberstro has quit []
ulfdoz has quit [Read error: 110 (Connection timed out)]
yziquel has joined #ocaml
coucou747 has quit ["bye ca veut dire tchao en anglais"]
coucou747 has joined #ocaml
ulfdoz has joined #ocaml
TypedLambda has quit [Read error: 110 (Connection timed out)]
Philonous1 has joined #ocaml
Philonous has quit [No route to host]
netx has joined #ocaml
jeddhaberstro has joined #ocaml
Associat0r has joined #ocaml
coucou747 has quit ["bye ca veut dire tchao en anglais"]
coucou747 has joined #ocaml
coucou747 has quit [Client Quit]
coucou747 has joined #ocaml
travis|away is now known as travisbemann
Camarade_Tux_ is now known as Camarade_Tux
SanguineV has quit []
Snark has joined #ocaml
shortc|desk has joined #ocaml
seafood has joined #ocaml
jeddhaberstro has quit []
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
toxygen has quit [Read error: 104 (Connection reset by peer)]
itouch has joined #ocaml
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
ttamttam has joined #ocaml
seafood has quit [Client Quit]
sporkmonger has quit []
<Myoma>
omake is just brilliant
seafood has joined #ocaml
seafood_ has joined #ocaml
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood_ has quit [Client Quit]
filp has joined #ocaml
seafood has joined #ocaml
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
Proteus has joined #ocaml
bluestorm has joined #ocaml
bluestorm has quit [Read error: 104 (Connection reset by peer)]
Yoric[DT] has joined #ocaml
Asmadeus has joined #ocaml
jknick_ has joined #ocaml
jknick_ has quit [Client Quit]
travisbemann is now known as travis|away
asmanur has joined #ocaml
mishok13 has joined #ocaml
im_alone has joined #ocaml
rwmjones has joined #ocaml
Yoric[DT] has quit [Read error: 110 (Connection timed out)]
rwmjones_ has quit [Read error: 104 (Connection reset by peer)]
xavierbot has quit [Read error: 113 (No route to host)]
Yoric[DT] has joined #ocaml
Myoma has quit ["Leaving"]
mib_nd7pw7us has joined #ocaml
<mib_nd7pw7us>
hi everyone
mib_nd7pw7us has left #ocaml []
hkBst has joined #ocaml
guillem_ has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
itouch has quit ["KTHXBYE"]
Proteus_ has joined #ocaml
Proteus has quit [Read error: 104 (Connection reset by peer)]
<Proteus_>
hey, good morning everyone
<Proteus_>
I'm working on developing some little games for some fun and experience and I had a little question. The toolsets I'm buildning to set up all the world content and management (which I'm looking to try wxpython and pyogre for the gui) are going to need to autogenerate a lot of code - such as reliably marking up models with all the physics, sound, event triggers etc - and from my bit of experience with ocaml I'm thinking that ocaml would be a
<Proteus_>
great language to do this. As the sole developer I'd like to be writing and modifying code generators than writing the massive amount of repetitive but predicitively unique code needed for assets and scripting. However, I haven't done code generation on this scale before so if any of you could confirm my choice or steer me to some other language with more elegant support for this I'd be very thankful.
<flux>
I don't know if some languages really excel at generating code, but ocaml is a great tool for parsing it
<Proteus_>
yeah, I love how good it is at parsing, but I was hoping it be good at transformation that generate code for other languages (lua, c, whatever)
<Proteus_>
Doing the logic and transformation in c++ would just be......... well...... yeah
seafood has quit []
<Proteus_>
plus, I had a professor who wrote a transformation system in ML (High Assurance Transformation System), obviously he was more interested in formal verificationn but not knowing much about topic I'm feeling out the option to do this in ocaml first
<Proteus_>
and i know FFTW did it
<im_alone>
Proteus_, c++ is not good for your purpose
<im_alone>
i recommend you ML or Java to write it
<Proteus_>
hrmm. Why java?
<Proteus_>
and by ML are you referring to SML or ocaml?
<Proteus_>
or does it matter
<im_alone>
both
bla has quit [Read error: 113 (No route to host)]
<Proteus_>
but I'm surprised that you would suggest java. Of course, in class it's all about GUI code and some server side stuff, so I'm hardly an expert.
seafood has joined #ocaml
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
<tsuyoshi>
Proteus_: I would recommend either ml or lisp
<Proteus_>
Why java? why lisp?
seafood has quit [Read error: 104 (Connection reset by peer)]
<tsuyoshi>
lisp has most of the same strengths that ml has for dealing with parse trees
<im_alone>
Proteus_, the 1st requirement could be that language has GC capability (the programmer has not to manage the control of memory)
<tsuyoshi>
I wouldn't recommend java but gc helps a lot
<im_alone>
then 2nd requirement is the maximum speed
<im_alone>
and the 3rd requirement is to do in lesser number of KLOCs
<im_alone>
you can use many libraries to write less
<tsuyoshi>
one thing that ml has over lisp is pattern matching
<Proteus_>
speed isn't a big deal. Unfortunately, most game engine libraries are written in c++ and I'll be generating c++. As far as lines of code: definitely. every function I don't have to write in c++ is like have a day on my life span.
<tsuyoshi>
lisp has ast parsing basically built in to the language
<Proteus_>
I'm not experienced with lisp, I'm aware of it's ast capabilities but I'm concerned that the code is less easy to read and modify and debug compared to ocaml and the code generators won't be modified often enough to keep all the relevent data in my head.
<Proteus_>
and yeah, lisps ast coolnes vs. ocaml's pattern matching and the bitstream lib Richard Jones is working on
<tsuyoshi>
I don't know about readability but ocaml is sort of easier to debug
<tsuyoshi>
lots of things that would be bugs in lisp are caught by the type checker in ocaml
<Proteus_>
the static typing is a plus over lisp _I think_
<Proteus_>
exactly my thinking
<Proteus_>
but again, why did you throw out java? I'm really curious.
<tsuyoshi>
with ocaml the vast majority of the time my programs work when I get them to compile
<tsuyoshi>
but I think I like lisp syntax better
<Proteus_>
at least you don't have to go back and pull your hair out debuging some type system issue on code you wrote 3 years ago with ocaml
<Proteus_>
what makes the lisp syntax more appealing? Simply your taste or more pragmatic reasons?
<tsuyoshi>
it's easier to remember the precedence rules, since there aren't any
<Proteus_>
im_alone, you list reducing the amount of code but you recommed java, which I've always seen as being quite verbose.
<tsuyoshi>
when I can remember ocaml syntax, it is pretty nice.. but I have to go check the manual quite often as I keep forgetting different details of the syntax
Yoric[DT] has joined #ocaml
<Proteus_>
when I first saw ocaml code I thought it was just masochistic. As I get used to it though, it's really growing on me.
<flux>
I would think it would be a much bigger pain to deal with trees in java than it would be ocaml
<tsuyoshi>
oh but one thing that annoys the hell out of me in ocaml is reserved words
<tsuyoshi>
especially "new" and "end"
<tsuyoshi>
I keep wanting to use those for variable names
<Proteus_>
java does have some graph libraries, but I've never used them so I don't know how good they are
<flux>
tsuyoshi, write an extension ;)
<flux>
eradicate_keyword end;;
<tsuyoshi>
flux: it's sort of intrinsic to the syntax those
<tsuyoshi>
though
<tsuyoshi>
maybe you could have { } instead of struct end
<tsuyoshi>
but maybe { } is already used for something else.. see I can't remember ocaml syntax
<Proteus_>
tsuyoshi, have you written much code generation code with lisp/ocaml?
<tsuyoshi>
and I've been using ocaml almost exclusively for 2 years now
itouch has joined #ocaml
<tsuyoshi>
no.. I think the last time I did code generation it was with m4
<flux>
tsuyoshi, ah, I was thinking only about begin/end
<tsuyoshi>
begin end I don't use at all, I just use parentheses
<tsuyoshi>
oh that's another keyword I want for variable names, begin
<flux>
just use begin_ or begin' like the rest of us ;)
<tsuyoshi>
I don't remember if it is the case with cl but in scheme there are no reserved words
bla has joined #ocaml
Yoric_ has joined #ocaml
<Proteus_>
If I actually go through with using ocaml in my game engine tools, or perhaps even the game, I think I'll write up some good real-world ocaml tutorials. Ocaml desperately needs to ease the learning curve.
<tsuyoshi>
so something like (let ((let (foo bar))) (+ let 1)) works fine
<tsuyoshi>
Proteus_: have you seen ocaml-tutorial.org?
Yoric[DT] has quit [Read error: 113 (No route to host)]
Yoric_ is now known as Yoric[DT]
<Proteus_>
tsuyoshi, yeah, but that series doesn't go into nearly enough depth
<tsuyoshi>
ah
<Proteus_>
tsuyoshi, and besides, tutorials addressing different topics, different approaches - the more the merrier
<tsuyoshi>
yeah, what do you think is missing?
<Associat0r>
Proteus_ : yes I would love to see more of that
<Associat0r>
Proteus_ : I am also working on a game engine in F#
<tsuyoshi>
one thing I think I will write up at some point is a comprehensive guide to the ocaml/c interface
<tsuyoshi>
the information in the manual is far from complete, and is actually a bit misleading in parts
<Proteus_>
ocaml-tutorial.org address a wide range of gener issues and it's a great place to start, I'm not disputing that. But look at the thousands of tutorials and dozens of books for python, ruby, c++
<Proteus_>
tsuyoshi, oh god yes, I really want a better tutorial for the FFI
<tsuyoshi>
Proteus_: sure sure, I'm just asking what is missing out of curiosity
<Camarade_Tux>
florent monnier's tutorial to the ocaml/c interface is actually quite good and thorough ;)
<Proteus_>
tsuyoshi, I can't think of anything off hand that would really fit their scope. But think about what I'm trying to do - manage a complex user interface tied directly to the rendering enging, assets, and, through code generation, the source code.
<Proteus_>
Camarade_Tux, holy shit. Thank you so much.
<im_alone>
our future computers will be multhreaded and SMPed, the sparc64s and partially em64t are the only correct way
<im_alone>
Java, C and C++ are ready for these future computers
<im_alone>
i don't now very well the multhreaded nature of SML
<Proteus_>
im_alone, yes, but I'm _generating_ C/C++ code and using TBB
<im_alone>
s/now/know
<Proteus_>
im_alone, you should also check out jocaml
<tsuyoshi>
hrm this tutorial doesn't really cover everything
<Proteus_>
tsuyoshi, what's missing?
<Proteus_>
;-_
<Proteus_>
;-)
netx has quit [Connection timed out]
<Proteus_>
and damn, for the c++ part it references french tutorials and I'm only in second semester college french.
<tsuyoshi>
Proteus_: well.. what's missing in this tutorial (and in the manual) is a good description of how the gc works
<tsuyoshi>
plus it doesn't describe the "float" and "noalloc" attributes
<Proteus_>
mmmm, yeah. An in depth document on that would be helpful.
<Proteus_>
though there is a bit about it in the o'reilly book
<Proteus_>
yeah, I just discovered the noalloc today on the forums
<tsuyoshi>
like if you just go by the manual, it says you should always put CAMLparam and CAMLreturn in your functions
<tsuyoshi>
but this is not strictly true
<Proteus_>
but I'm not sure I fully understand when to use it or what the risks/drawbacks are
<im_alone>
the deductive system requires a lot of computation
<Proteus_>
tsuyoshi, if you could do it, writing up something about that would be a nice contribution to the community
<Proteus_>
(and me)
<tsuyoshi>
you can use noalloc (and omit CAMLparam/CAMLreturn) if you don't allocate any memory from the caml runtime or raise any exceptions
bluestorm has joined #ocaml
<Proteus_>
so if you're basically just calling C and saying "go" and forgeting about it from the caml side?
<tsuyoshi>
yeah
<Proteus_>
makes sense
<Proteus_>
I'd also really like good tutorials with applicable examples about how to optimize ocaml code for speed
<tsuyoshi>
actually if you only allocate once, under certain circumstances you can omit the CAMLparam/CAMLreturn too
<tsuyoshi>
not sure if noalloc is safe though
<Proteus_>
will using the FFI make the running program more fragile in any way?
<tsuyoshi>
well, it's easier to write buggy c than buggy ocaml
<Proteus_>
ha, well yeah
<flux>
and chances are its failure modes are more difficult to find
<Proteus_>
Associat0r, what sort of engine are you building. Also, out of curiosity, why F# and not ocaml?
<flux>
little pieces of code can work, but not when you do something really useful
<tsuyoshi>
the only time I ever ran an ocaml program through a debugger was to find a bug in a c binding I wrote
<Proteus_>
interesting
<im_alone>
i don't see why the ibm powerX architecture has not multithreads
<tsuyoshi>
gah.. it's raining.. I was going to buy an umbrella today but somehow I failed to do so
<Proteus_>
I've thought about how practical it would be to build a little library for using SSE extensions through the FFI
<Associat0r>
a 3D game engine, F# for easy interop and I am used to visual studio so why not?
<Associat0r>
Proteus_ : also I can't do without op overloading
<Camarade_Tux>
Proteus_, about optimizations, what kind of optimizations do you want ?
<Proteus_>
Associat0r, I'm using Ogre3D for rendering
<Associat0r>
Proteus_ : I am doing physics and rendering myself
<Proteus_>
Camarade_Tux, I'm working on a game engine and as a bioinformatics student, my research is in AI and analyzing huge datasets. In all cases, any speedup is extremely useful and potentially saves money
<Proteus_>
Associat0r, that's really impressive! How did you learn the ins and outs of desinging and coding stuff like that?
<im_alone>
the advantage of the 1000 threads vs 1000 cores is that 1000 threads share one bigger cache, and 1000 cores need 1000 tiny caches!
<gildor>
im_alone: untrue
<Associat0r>
with physics I started from the hecker and baraff papers papers years ago in C++ and self studying the math from books like engineering mathematics
<Proteus_>
Camarade_Tux, so take a neural network. you've got a neuron sending a spike out to four other neurons. I can do that simultaneously with some of the new chips. On another front, let's say I want to modify three sounds at once with the same waveform - same deal.
<gildor>
im_alone: you can have 1000 core that share the same bigger cache (in RAM)
<Associat0r>
graphics stuff I learned from realtime rendering and stuff around the net
<flux>
gildor, 1000 cores sharing same memory? really?
<im_alone>
gildor, then there will be a bottleneck in the bus of RAM
<flux>
perhaps an L3 or some such, but definitely not L1 cache
<gildor>
im_alone, flux: no if this cache is read-only
<Proteus_>
Associat0r, for graphics there's lots of material out there, but there really isn't on designing an engine architecture. How are you approaching that?
<gildor>
it will be automatically loaded into L2 cache
<im_alone>
who care of the hardware hazards!
<gildor>
and not invalidated
<Associat0r>
Proteus_ : there are some books from Eberly
<im_alone>
gildor, untrue, if this cache is read-only, you will be fighting the requests from 1000 addresses!
<gildor>
flux, im_alone: as long as your cache is read only you can have something pretty efficient
<flux>
gildor, hmm, I don't quite understand what is a read-only cache?
<flux>
also known as ROM?-)
<gildor>
im_alone: what is "the requests from 1000 addresses"
<Proteus_>
yeah, I'm on the interlibrary loan waititing list to get Eberly's book.
<gildor>
flux: read-only is just that you don't write in it ;-)
<Proteus_>
Associat0r, what sort of design are you using?
<gildor>
it can be a bigarray for example
<flux>
gildor, let's say you have 1000 pcs of 100MHz cpu's and all of them say "read byte n" where n is the cpu number in the same cycle
<flux>
how is that not going to saturate the memory bus?
<im_alone>
gildor, the LOAD instruction requests the one word of memory giving him an address
<Associat0r>
Proteus_: I still have to decide on that since I haven't used F# for long yet
seafood has joined #ocaml
<gildor>
im_alone: yes but once a LOAD instruction happens, the data should be in the processor cache
<Associat0r>
Proteus_: but it will probably a hybrid OOP FP design
<gildor>
(L2 or L1 or L3 for next intel processor)
<flux>
gildor, so you're thinking the case where the local caches have already been filled?
<im_alone>
the cache can't respond the requests of 1000 addressings at same time!
<flux>
unless it's a quantum cache!
<flux>
;)
<im_alone>
wowwwww!
<Proteus_>
Associat0r, have you tried some of the other open source engines out there like Ogre. If so, what are your opinions of them?
<gildor>
flux: indeed, if you are manipulating data that cannot fit in the cache of processor (over 12MB) you have a problem
<Associat0r>
Proteus_ : i want to explore FRP too but from what i read perf is nog going to be well with lots of interactions
<Proteus_>
Associat0r, I'm surprised you'd use F# for something as math heavy and performance critical as the render system
<Associat0r>
Proteus_ : I only looked briefly at Ogre some years ago, but never used any myself, but I hear from people these days it is easier to just write something from scratch than to get used to Ogre
<im_alone>
if i born differently then i would have 100 fingers instead of 20, 16 hands and 8 legs
<Proteus_>
Associat0r, ogre has enormously improved over the years
* im_alone
go to lunch
<Proteus_>
Associat0r, and it's being used by some pretty cool games
<Associat0r>
Proteus_ : well it is more like a proof of concept, the speed is along he lines of C# currently and I suspect it to improve later on with all the midori and bartok stuff going on when .NET gets SIMD optimzations
<Associat0r>
Proteus_ : the of Ogre were very recent and from some guys in the industry
<Associat0r>
Proteus_ : so I take their word for it
<Proteus_>
Associat0r, I've always been extremely leery of .NET. I'm all for exploring the idea of managed code environments, I just hate getting locked into a system so tightly as you do when you code for .net
<Associat0r>
Proteus_ : same here but there is always mono
<Proteus_>
Associat0r, well, in any case, the competition to Ogre doesn't really come close, at least in terms of interoperability, features, and highly active userbase. The LGPL/BSD open source competition, I mean
guillem__ has joined #ocaml
<Proteus_>
Associat0r, I've never had a chance to give mono a try. How does it hold up>
guillem_ has quit [Connection timed out]
<Proteus_>
Associat0r, I've been hearing of some big companies adopting it
<Proteus_>
I think second life just did
<Proteus_>
Tangentially - is there some technical reason why the ocam compiler doesn't take advantage of SSE?
<tsuyoshi>
I don't think it would be difficult to add sse support to the code generator
<flux>
I suppose not, but I guess the amount code that could take advantage of it is so small that the ocaml team cannot put much effort to such things
<Associat0r>
Proteus_: I heard that that wikipedia's search system is written in C# using mono
<flux>
how much SSE code could a compiler make use of?
<Proteus_>
no, no, I mean the resulting binary/runtime
<Proteus_>
or maybe I'm totally ignorant here and it does
<tsuyoshi>
well.. like the sse builtins that gcc has, you could add that to ocaml without much trouble
<flux>
tsuyoshi, what kind of builtinds does gcc have?
<Proteus_>
I know gcc takes full advantage of SSE
<tsuyoshi>
heh I don't remember.. I saw it in the gcc manual but I never used it
<Proteus_>
it's just a flag
<tsuyoshi>
Proteus_: afaik you don't need any runtime changes for sse
<flux>
proteus_, so what does that mean in practice?
<flux>
by "compiler" I meant the resulting compiler binary
<flux>
how does symbol manipulation map into SSE instructions?
<Camarade_Tux>
Proteus, on x86-64 it uses sse2, the official line is that if you want performance, you can't be running x86 anyway
<Proteus_>
so the ocaml team is mostly focusing on 64bit?
<Proteus_>
in other words, what should I be using if I want performance?
<Proteus_>
I'm new to game dev - I'm mostly designing by intuition rather than experience or education. These are the sort of resources I've been looking for.
TaXules has quit [Connection timed out]
<flux>
btw, any suggestions on a decent 3d-format one could export from blender?
<flux>
I tried some.. somesome which I can't quite remember now, but the export messed up the normals bad
<Proteus_>
collada?
<Proteus_>
obj?
<Associat0r>
also flux has a game engine written in ocaml
<flux>
yeah, I wonder if anyone's ever managed to compile it :)
<Proteus_>
flux, do you have a page and/or sources up? I would really love to see how you managed it
<Proteus_>
Associat0r, what sort of game are trying to create?
<Associat0r>
I didn't try to compile it, I kinda looked through it how it compared to mlgame
<Associat0r>
Proteus_ : the difference of approaches seemed intersting
<Associat0r>
I mean flux
<flux>
well, goba is not a engine, it's the end product
<flux>
I support an engine could be extracted from it, for certain kinds of games
<flux>
mlgame is bound to be more generic, right?
<flux>
perhaps I should take a look at mlgame to see how I could refine my approach
<Associat0r>
Proteus_ : I am not 100% sure yet, back in the days win C++ I was writing a futuristic race simulation, it i currenlty on hold, I guess I will try to port it to F#
<Associat0r>
and see from there
<flux>
btw, I'm sure the blending routines could use some SSE love there :)
<flux>
(I cache all generated bitmaps so I can avoid blending them in realtime as much as possible, but that consumes memory - a lot)
<Associat0r>
flux: yeah mlgame also more functional
<flux>
yes, I'm not very functional in the large :)
<flux>
(mmm, "goba isn't..")
mattam has joined #ocaml
<Associat0r>
flux: yeah goba uses classes heavily, I think I will go for a hybrid approach also
<Associat0r>
functional where possible, and classes where it makes more sense
<Associat0r>
right now I am still figuring that out
<Proteus_>
I read, not infrequently, that people can do without the object system with good use of functional programming - I don't get how this is possible. Also, what sort of overhead is incurred when using classes/objects?
<bluestorm>
design patterns shit overhead :-'
<Associat0r>
Ocaml has a huge overhear fro mwhat I hear
<Associat0r>
ocaml classes
<bluestorm>
hm
<Proteus_>
Is there some documentation on this?
<flux>
proteus_, perhaps the computer language shootout can give you some insight
<bluestorm>
Associat0r: do you have any pointers on that topic ?
<Associat0r>
I don't think the ocaml shootout uses classes anywhere
<bluestorm>
well OOP is not a very natural style in most cases
<Associat0r>
I have no pointers i just heard it
<jynxzero>
It'd not be the shootout coz it's so slow and it'd make O'Caml look bad. :)
<bluestorm>
i don't think Ocaml OOP is that slow
<flux>
shootout has a method call benchmark, no?
<Proteus_>
flux, my understanding is that ocaml's compiler only generates fast code when you use a verbose imperative style
<flux>
proteus_, perhaps so, but then there's the 90/10 rule - you spend 90% of the time on 10% of the code ;)
<bluestorm>
Proteus_: i think you're approaching the question the wrong way
<bluestorm>
you should code your things in the most easy and simple way
<bluestorm>
then profile it and optimize the performance-demanding parts
<Proteus_>
I have some situations where I'd like to have a very large number of objects communicating with eachother, but people tell me that it's better to have a big set of functions explicitly calling eachother.
<bluestorm>
basing general design consideration on performance issues is helpless and tends to make bad software
<Proteus_>
bluestorm, I completely agree, but there are certain cases where I need to drill down for performance
<bluestorm>
well probably not on the whole app.
<bluestorm>
Proteus_: if you're afraid of OOP overhead
<bluestorm>
you can use OOP as a mid-size design tool
<bluestorm>
while keeping "basic" types for the small "objects"
<Proteus_>
bluestorm, I'm a bioinformatics major so I deal with complex functions on enormous sets of data, and my AI work is on a varient of spiking neural networks and evolutionary computation
<mfp>
Proteus_: imperative isn't always faster than functional in OCaml actually
<Proteus_>
mfp, enlighten me
<mfp>
(algorithmic considerations aside)
<Associat0r>
bluestorm: you can use OOP as a mid-size design tool << that is good advice
<bluestorm>
well a good tail-recursive function could be faster than a loop + reference
<bluestorm>
(blah blah "registers" blah blah)
<mfp>
the write barrier (caml_modify) you bump into with imperative code can be more costly than allocation
Yoric[DT] has quit ["Ex-Chat"]
<Associat0r>
for most innerloop stuff imperative is faster
<Proteus_>
is there a technical reason for the less than stellar perormance of the object system?
<Proteus_>
performance
<mfp>
for instance, I've found that a functional queue (the traditional encoding with two lists) is typically faster than an imperative one in OCaml
<mfp>
Proteus_: row polymorphism and the need to do method lookup dynamically
<mfp>
but it's not _that_ bad really
<bluestorm>
Proteus_: for obvious sanity of mind reasons, all Ocaml methods are what C++ calls "virtual"
<flux>
and separate compilation
<Proteus_>
mfp, I know there are cases like that where functional>imperative but I don't understand why it's the case so I don't know when to apply what where.
<bluestorm>
(if i understand correctly that C++ insane idea)
<mfp>
if you're going to call a method repeatedly, you can also get a closure
<bluestorm>
so there must be cases where C++ benefits from the flaws of his OOP model and get faster things
<mfp>
method foo a b c = ... -> let f = obj#foo in .... (* in inner loop *) f x y z
<mfp>
leaving you with the indirect jump + likely branch misprediction
<jynxzero>
Proteus_: FWIW my own very simple benchmark suggests a method call is about 7 * more expensive than a function call.
<flux>
mfp, nice trick, hadn't thought of that
<Proteus_>
7 TIMES. That's far more than I expected
<mfp>
jynxzero: a call to a known function (which can be inlined), or an indirect jump?
<jynxzero>
A known function.
<jynxzero>
With 1 argument, I guess that probably makes a difference.
<mfp>
well
<mfp>
o#g should be compared to let f g = ... g whatever ....
seafood has quit [Read error: 110 (Connection timed out)]
<mfp>
there's an extra "degree of freedom" (indirection) in the method call
<Associat0r>
Proteus_ : in F# I noticed that in functional styles mostly copying of record member refences slowed stuff down, so that is where mutable imperative code makes sense but that could easily change in the future with many cores
<jynxzero>
If I pass the function as a parameter, so it can't be inlined, it's pretty much exactly the same as the method call.
<mfp>
jynxzero: hmm I think it'd depend on whether it's always the same class at a given call site
<mfp>
the runtime caches method lookups
<Proteus_>
whatever the cost though, certain problems just make sense with objects. I've thought about writing an aspect weaver preprocessor, since aspects make sense sometimes to, and also just make sense sometimes. I imagine a code base with a hydra of objects, modules, aspects, and flatfiles of functions could get nightmarish.
<mfp>
so subsequent calls are much faster if the class hasn't changed
<jynxzero>
Ah, cunning.
<bluestorm>
Proteus_: do you have an example of problems "making sense in object" ?
<mfp>
otherwise, it uses binary search over the methods from the object
<Proteus_>
GUI code, object databases, stuff like that
<bluestorm>
in my experience it is very rare that you can't get a neat functional translations with equivalent benefits
<jynxzero>
Sometimes I find myself basically re-implementing "object orientedness" using a record of functions... that's usually when I start using the OO stuff in OCaml.
<bluestorm>
hm "object database" o_O
<mfp>
Proteus_: if you don't need inheritance / extensibility, objects can be replaced with records containing functions
<bluestorm>
well you necessarily need objects to do object databases, but what's the point of object databases if you don't need objects at the first place ?
<jynxzero>
Eg, the other day I wanted a file handle style object, but wanted to allow client code to provide new implementations for extensibility, so I used the OO stuff.
<mfp>
in other cases, you can use functors instead of objects --- when you don't need late binding & multiple kinds at once
<jynxzero>
Would people here generally implement that differently?
<bluestorm>
jynxzero: what kind of "new implementations" ?
<mfp>
you can sometimes use polymorphic variants for extensibility
<bluestorm>
(what kind of operations do you use on a file handle ?)
<mfp>
if new implementations don't extend the interface, the record of functions does
<jynxzero>
bluestorm: Eg, files where the data comes from inside a compressed file, instead of straight off of the filesystem.
<bluestorm>
hm
<bluestorm>
streams ?
<mfp>
bluestorm: I guess the problem is with e.g. normal sum types being closed, so you cannot extend the existent functions to handle your own data
<jynxzero>
Would be great if you only ever consume the file from start to end.
<mfp>
and we're back to the expression problem
<rwmjones>
use Unix.open_process_in ...
<bluestorm>
jynxzero: or from start to somewhere
<jynxzero>
Yeh, but no good if you want random access, and other file operations (deleting, getting file permissions etc)
<bluestorm>
of course, it depends on the kind of interface you want to your data structure / object
<jynxzero>
I couldn't see a neat simple way of doing it other that: record with functions, or an object.
<bluestorm>
module + interface ?
<jynxzero>
It feels a bit wrong using the OO stuff in OCaml coz everyone seems to hate it, but it seemed like the best tool for the job.
<bluestorm>
hm
<bluestorm>
i'm not sure people hate it
<mfp>
hmm polymorphic variants
<bluestorm>
they just generally don't need them
<bluestorm>
mfp: i've played with polymorphic variants a bit and they're fun
maattd has joined #ocaml
<bluestorm>
i actually think i've not used them to "extend" but to "restrict" actually
<jynxzero>
mfp: How would you do it with polymorphic varients? I've tried to use them for a few things, but the typing always seems to get really complicated.
<mfp>
module type FILE = sig type t val someop : t -> whatever val op2 : t -> t -> whatever end;; then you have an implementation with module Normalfile : FILE with type t = [`File of string] = struct ... end
<jynxzero>
Associat0r: Thanks, I'll have a read when I'm not meant to be working. :)
rwmjones_ has joined #ocaml
<mfp>
to extend, module FileOrCompressed : FILE with type t = [ Normalfile.t | `Compressed of _] = struct .... let someop = function #Normalfile.t -> Normalfile.someop | `Compressed x -> .... let op2 = .... end;;
<rwmjones_>
is anyone from inria on this list?
<mfp>
iow. you keep extending the functions with let f = function #oldtype -> ... | `New_type1 x -> ... | `New_type2 x -> ...
<jynxzero>
So, I have a "VFS" module with, for example a "close_file" function. Is it not the case that this function would have to know how do close all possible files? I don't see how client code could extend that function without changing it.
<mfp>
with polymorphic variants, it'd be done as shown above
<mfp>
you keep extending the type of files handled by the function
<mfp>
*functions
<mfp>
by defining the extension in terms of the previous one
<mfp>
Jacques Garrigue's paper expands on this
<mfp>
OO makes it easy to add a data type (new class), polymorphic variants make it easy to add new functionality (a new function)
<jynxzero>
I need to read the paper I guess, it doesn't seem very modular because each client module which wants to add a filetype ends up with it's own close_file function.
<Proteus_>
so if objects have such a big overhead, what about the module system?
bzzbzz_ has quit ["leaving"]
<Associat0r>
Proteus_ : IIRC the ovehead was huge compared to .NET
<Proteus_>
hahaha damn it.
<Associat0r>
Proteus_ : 10 times I think
<Proteus_>
oh great, now Jon Harrop will have more to spew
<Associat0r>
Proteus_ : but you have to test for yourself to see if it is true
<Proteus_>
do you have any idea how the performance of the module system compares to the object system?
<Associat0r>
Proteus_ : I have no idea
<Associat0r>
Proteus_ : btw there was some optimization article by Xavier somewhere let me find it
<Proteus_>
rwmjones_, I discovered your bitstring module today. Thank you for releasing it.
<Proteus_>
it looks increadibly useful
<rwmjones_>
Proteus_, what are you going to use it for?
<mfp>
Proteus_: function calls through a functor preclude inlining and force an indirect branch (possible branch misprediction)
<mfp>
essentially, when you have module M(N : sig ... end) = struct .... N.foo x y end
<mfp>
the call will be as fast/slow as let foo = obj#foo in .... foo x y (* no method lookup involved, already done & cached before *)
<mfp>
the cost is no inlining + indirect branch
<mfp>
if function call + branching = too slow, you can defunctorize manually
<mfp>
using for instance something like Camlp4MacroParser's INCLUDE
<Proteus_>
rwmjones_, right now I'm working on a game engine/game. I'm looking to conviently build meta-containers for art assets and all the markup that needs to go with them and being able to combine normal string manipulation, for doing things like orienting a .obj model correctly, at the same time I'm working with binary formats and doing it elegantly is really nice. I'd also like to recognize/manage various binary files without much hassle and w
<Proteus_>
ithout switching to another language or adding complexity some other way.
<Proteus_>
that's what I'm thinking at the moment, anyway. Like I said, I found it this morning.
<Proteus_>
Mainly it just looks like a feature rich and immenently useful tool that's being actively maintained - something the ocaml community needs more of
marmotine has joined #ocaml
<im_alone>
i can't have a Sun M9000 server ( x4 cores, x2 threads per core, sparc64 vii ) ):
<rwmjones>
Proteus_, make sure you use the latest version then, because it has some significant performance advantages
<Proteus_>
sweet
<Proteus_>
rwmjones, I've been appreciating your posts in the mailing list for a while but I've been wondering: Does a big company like Redhat use ocaml internally? I never caught whether you just loved ocaml or whether you used it professionally.
<rwmjones>
well we use it for a few things ... I wouldn't say it's used very much internally right now
TaXules has joined #ocaml
filp has quit ["Bye"]
<Proteus_>
ah, too bad. I always get hopeful when I hear a major company is not only not chained to MS products but also uses good languages that don't get enough attention.
<im_alone>
Proteus_, the M$ and Intel products are plagued of many errors
<Proteus_>
Intel?
<Proteus_>
what are you referring to?
<im_alone>
why the latest microprocessor Nehalem is still using the ISA 8086?
<Proteus_>
think about it
<Proteus_>
think about how increadibly entrenched it is and think about all the alternatives that have died out
rwmjones_ has quit [Read error: 104 (Connection reset by peer)]
<mrvn>
Proteus_: and now think why they died.
<Proteus_>
you could have whole flamewar parties going over that one
<im_alone>
Intel and M$ killed the innovations from the anothers
<mrvn>
Proteus_: no windows, no games, no pron, no mainstream customers
<Proteus_>
well, there is that.
<Proteus_>
but many really began to die while there was still competitoin there
<mrvn>
The performance/quality of the cpu is way secondary to that.
<mrvn>
Proteus_: cpus that started dying 20 years ago?
<mrvn>
I was thinking more like IA64.
<Proteus_>
MIPS used to make fantastic processors with a good instruction set but they were set back in large part because of bad management both internally and with partners like SGI
<mrvn>
MIPS still is pretty widespread, but embedded now.
<Proteus_>
right
<mrvn>
same as arm
<im_alone>
IA64 is worser than sparc64 in terms of performance/quality/practicility
<Proteus_>
you're talking about Itanium?
<mrvn>
Proteus_: yes
<Proteus_>
and have you considered the success of the Cell processor?
<mrvn>
Proteus_: what success? It is not like they have a large market share
<Proteus_>
Itanium had a lot of design decisions that made it less viable in the areas that sun is focusing on
<Proteus_>
no, but it's a radically different architecture
<Proteus_>
which is successful
<im_alone>
the next big jump will a processor like 64 cores, 2 threads per core, and many medium L1 caches, four L2 caches and a bigger L3 cache
<Proteus_>
you're talking about niagra, sun's processor
<Proteus_>
that's pretty much it
<Proteus_>
though it's really only good at certain kinds of loads like web/db. still.
<Proteus_>
also 'M$'? really.
<Proteus_>
this is an argument that doesn't really belong in this channel though.
<Proteus_>
I'm not even really arguing
<Proteus_>
since I don't disagree, but it's still not relevant
<im_alone>
Itanium is too slow compared to it
<Proteus_>
compared to what?
<im_alone>
to the processor of 128 threads
<Proteus_>
threading really really isn't appropriate for a lot of the problems the Itanium was built for, and having 128 SMT doesn't say anything about how well they can be used
<mrvn>
im_alone: There is a 64 core mips system that eats 50W out there.
<mrvn>
Going to 128 threads is not that much of a jump.
<im_alone>
Proteus_, in computation, the bigger problems have to be solved better efficiently with many threads than with higher clocks
<mrvn>
im_alone: not true.
<Proteus_>
to get back on the topic of ocaml, I had read about a summer of code initiative to build a working cuncurrent GC - it's the end of the summer; have any results come out
<Proteus_>
very not true
<mrvn>
Usualy you specify an \alpha and \beta factor. \alpha being the part that can not be parallelized and \beta the part that can.
<Proteus_>
I work on very very big problems. sometimes you can parallelize and sometimes you just can't
<mrvn>
Some problems have a high \alpha and some a high \beta. Only the later benefit from threading.
<mrvn>
Sometimes some threading is good but not too much. After some limit you loose more in the synchronization between the threads than you gain by more threads.
<Proteus_>
of course it depends on how much intercommunication is necessary, but whatever
<Proteus_>
what happened with the concurrent GC?
<im_alone>
mrvn, loose? why won't add more hardware capabilities to the synchronization of threads?
<im_alone>
i remember, the MOESI was ultimately improved buy we need more!
<im_alone>
as e.g. the mix of Dragon and MOESI
<bluestorm>
hm
<bacam>
I wonder if using Boehm's GC allows for cross-language collection.
<bluestorm>
apparently the Jsoc meeting is at Sept 11-12
<mrvn>
Boehm is speculative and on 32bit that has many false negatives
<mrvn>
on 64bit too if you use ram below 4G
<im_alone>
program in mind of 64 bit, multithreaded and multiprocessed
<mrvn>
Still. The ocaml gcc is a moving and generational GC. Way way better than boehm.
<im_alone>
so care much of threading safe, reentrant, well synchronized and avoid the livelocks and deadlocks
<mrvn>
is boehm thread save?
<bacam>
mrvn: Sure, but that's why it would be useful for mixed C/ocaml code.
<flux>
I thought Boehm wasn't supposed to be the end product, but rather used for a proof-of-concept?
<mrvn>
How much do you want to mix? If you just have a few C stubs then one can add the needed GC directives there.
<flux>
although Boehm can work non-speculatively too, can't it?
<im_alone>
if the sw layer and hw layer have not made for their purposes, bye-bye
<mrvn>
flux: if you get a C compiler that tags its data types.
<mrvn>
and not sre if boehm has any support there
<mrvn>
s/sre/sure/
<rwmjones>
boehm is used for real inside firefox ...
<rwmjones>
(lot of good it does them, my firefox still leaks memory like a sieve)
<mrvn>
.oO(No wonder it uses so much ram)
<im_alone>
worser is the required buggy flash player inside of firefox to navigate some sites
<im_alone>
flash player closed my firefox in many times
<mrvn>
Problem is that if you have memory allocated at 0x100000 and have int i = 0x100000; somewhere on the stack then that ram will not be freed.
<im_alone>
i can't isolate the failures of the flash player
<Camarade_Tux>
people say windows is unstable, they will soon say that flash is, plus the npapi is not fit for today's need
<mrvn>
That problem is trivial to fix: apt-get remove --purge flash-plugin
<flux>
it would be nice if plugins didn't need to reside in the same address space as the rest of the browser
<flux>
and in addition, or alternatively, each tab should be a process of its own
<bluestorm>
flux: konqueror's flash plugin is outside
<mrvn>
I truely don't get why they can't fork a player externally.
<mrvn>
flux: what for?
<flux>
mrvn, for one, each would have a javascript interpreter of their own
<flux>
mrvn, for second, it would enable more strict permission limits (enforced by the OS)
<flux>
I'm under the impression that when js is running in one tab, it's not running in others
<flux>
also flash-videos seem to stall if there's something busy in another tab
<Camarade_Tux>
that's npapi, from what I've recently from my recent work on npapi, everything is in a single thread even for several instances of the plugin (or something like that)
<im_alone>
buggy flash plugin close firefox => close every tabs of firefox => damn flash!
<im_alone>
the correct way is flash will close its own tab, not from else.
<flux>
right, the obvious one: bugs would more likely be isolated to crashing a single tab, not all of them
<flux>
I think some research group was looking into making a more secure web browser, I guess they use an approach like this
<im_alone>
or considerate one tab per process instead of one tab per thread
Jedai has joined #ocaml
<mrvn>
flux: java script should be a thread. And why should a tab crash?
<mrvn>
When a thread segfaults doesn't that kill all threads?
<bluestorm>
konqueror already has out-of-process flash plugin
<flux>
yes
<flux>
and doing otherwise wouldn't be very smart anyway
<bluestorm>
and java-plugin
<flux>
mrvn, I don't know, but firefox does certainly seem to be able crash at times, and it occurs when entering a site
<mrvn>
So you need a process per tab/javascript/flash
<im_alone>
firefox has to be redesigned for one-tab-one-process
<flux>
if the logic to interact with a site was in an isolated process, it only that would need to go down
<bluestorm>
mrvn: i think flash only use one process for the whole thing
<mrvn>
im_alone: No. Just move the buggy parts into processes: java/javascript/flash
<flux>
mrvn, who says the rest isn't buggy also?
<mrvn>
flux: my browser doesn't crash and I have neither java nor flash.
<flux>
perhaps your choise of web sites differs from ours
<mrvn>
I'm not saying it can't be buggy. It just isn't that buggy.
<flux>
although I do have them, java-sites are quite rare. so flash would be a more likely candidate.
<mrvn>
The flash plugin is a major source for crashes.
<flux>
it would definitely be a good first step to move plugins to their own processes
<flux>
one could even renice them if they are rude
* Camarade_Tux
still has to review the rest of the webkit-gtk api to make more complete ocaml bindings and write a super browser that will p4wn firefox
<im_alone>
for many web servers, java is the champion over php ; for many web clients, flash is the champion over javascript
<flux>
camarade_tux, good luck :)
<im_alone>
it's the true reality
<flux>
im_alone, mm, I don't know, ajax is mighty popular don't you think?
<mrvn>
Camarade_Tux: ocamlbrowser?
<Proteus_>
it's sad that java and php are the most popular server side languages
<flux>
I'm thinking practically all "web 2.0" sites have javascript, but it takes a special site to have flash
<im_alone>
Proteus_, java is not popular in the client side
<mrvn>
way too many sites have flash. Lucily proper sites work without too.
<flux>
if you switch javascript off, you will lose a lot more functionality than by switching flash off
<Camarade_Tux>
flux, mrvn, webkit-gtk is an incredible rendering engine, you can turn it into a browser in under 150 lines of _C_ code, imagine what could be done with ocaml ;)
<flux>
basically, with the latter option you lose youtube ;)
<Proteus_>
the AdBlock Plus plugin saves me sooooo many cpu cycles.
<mrvn>
flux: good riddance
<flux>
butbutbut it has kittens :(
<mrvn>
youtoube.dl
<flux>
hey, I don't want that crap on my hd ;)
<flux>
besides mplayer doesn't mplay them as well as flash
<flux>
I have audio synchronization problems
<flux>
(..not that I _would have_ downloaded those videos, no sir..)
<mrvn>
flux: yeah. I miss support to stream to mplayer. Major bug in youtube.dl
<im_alone>
the vision quality of youtube is worser than the DVD quality
<flux>
heh
<flux>
no kidding
<flux>
perhaps it's on par with vcd?
<im_alone>
on par to h.323
<Camarade_Tux>
there's h.264 in recent flash versions (even in 9) ;)
<Proteus_>
I've been getting some good ideas for smart phone apps and I've been researching the various platforms the past few days - it's depressing. Do the compiler devs have any plans to add targets for targeting the cpus in major use in the embedded sector?
<Proteus_>
arg, bad sentences. sorry
<flux>
proteus_, perhaps it would be a reasonable option to port ocamlrun
<Camarade_Tux>
well, you can have a cross-compiling ocamlopt to arm :)
<flux>
compile ocaml to java and run that on your smart phone ;)
<Proteus_>
I didn't know ocamlopt supported arm
<Proteus_>
flux, that's what I'm beginning to think
<flux>
I wonder if anyone's used that for anything
<flux>
the idea sounds intriguing
<bluestorm>
Proteus_: there's been "ocaml on iPhone" work
<Proteus_>
bluestorm, that would be fabulous
<bluestorm>
and yes ocaml-java may allows one to do interesting things
<Camarade_Tux>
well, having a toplevel available everywhere is really good, and you can "advertize" ocaml everywhere too ;)
<Proteus_>
does ocaml-java let you take advantage of java's superior multithreading?
<bacam>
ocamlopt only supports the old arm ABI at the moment
<Proteus_>
bacam, that's what I thought, I was getting a little confused there.
<bacam>
Supporting the proper softfloat abi that everyone's using would be a pain (you have to allocate register pairs), but hardware fp shouldn't be that hard.
<flux>
proteus_, I don't know (I expect it does, if it's not just ocamlrun that's been ported), but ocaml programs are very much allocation-heavy, which the java gc might not be tuned for
<Proteus_>
flux, are there ways around the allocation problem?
<flux>
I don't know
<flux>
there could be
<bluestorm>
w00t
<flux>
pre-allocating perhaps?
<bluestorm>
in the still-to-come-3.11 changelog
<bluestorm>
"- Printexc library: new functions "print_backtrace" and "get_backtrace" to obtain a stack backtrace of the most recently raised exception. New function "record_backtrace" to turn the exception backtrace mechanism on or off from within a program."
<flux>
bluestorm, yeah, that sounded very interesting
<flux>
finally one can dump out that without terminating
Philonous1 has quit ["Leaving."]
Philonous has joined #ocaml
<Proteus_>
flux, so what I'm working on is using the touchpad, mic, and accelerometer to build an app that lets you record samples, manipulate them, compose synth arrangements, and a minamalist audio sequencer so you can use your smartphone to fluidly compose music based on the surrounding environment. Also, I have a way to use the wifi/3g links to let a group of people use the samples/instruments they've built and jam together in real time. The math
<Proteus_>
for manipulating audio on relatively weak hardware like this would have to be optimised like crazy, but for the engine and interface I would LOVE to be able to do it in ocaml and not java or objective-c
<Proteus_>
it looks like the ocaml+iphone work requires a jailbroken phone
<Camarade_Tux>
well, fast everything does...
<Proteus_>
sigh
pango_ has quit [Remote closed the connection]
<Proteus_>
I know absolutly nothing about objective-c beyond what the name implies. Google's android, despite being otherwise impressive mandates that apps be written only in java
jeddhaberstro has joined #ocaml
<mrvn>
java: compile once, run neverwhere
authentic is now known as fmu
fmu is now known as authentic
pango_ has joined #ocaml
<Proteus_>
have any of you had experience using ocaml-java?
ttamtta1 has joined #ocaml
<Proteus_>
is there an up to date interface to python?
<Proteus_>
pycaml only supports 3.04
<Camarade_Tux>
there's camlpy too afaik ?
<Proteus_>
ooooooooh ok. I just mixed up the order
<Proteus_>
thanks
<Camarade_Tux>
you haven't seen the sdl/gl-binding's names yet ;)
<Proteus_>
hah
<Proteus_>
wxcaml is in the same state - abandoned in 2004
<jeddhaberstro>
There is a different GL bindings that's up to date with opengl 2.1
<Proteus_>
haskell has an up to date binding to a great gui library but ocaml doesn't? that's just sad.
ttamttam has quit [Read error: 110 (Connection timed out)]
<Proteus_>
Would it be a waste of time trying to use SWIG to make ocaml bindngs? I've never used it, but they say SWIG supports ocaml
tomh has joined #ocaml
<Camarade_Tux>
ocaml has tk, gtk and sdl (and gl) atm, that's already quite a lot but of course, more is welcomed
<Proteus_>
wxwidgets is sort of higher level than gtk and qt
<Camarade_Tux>
SWIG : as far as I'm concerned, I absolutely don't know how to use swig
<Proteus_>
speaking of which, is anyone working on an ocaml interface to qt?
<Camarade_Tux>
it's an ocaml summer project ;)
<Proteus_>
I hope it isn't as disappointing as the concurrent gc project
<Proteus_>
though I guess building an interface isn't nearly as complex
<ttamtta1>
Hello
mishok13 has quit [Read error: 110 (Connection timed out)]
guillem__ has quit [Remote closed the connection]
<ttamtta1>
Proteus_: what are the news about the OSP gc project?
<Camarade_Tux>
Proteus_, from the beginning it has been stated that concurrent-gc wouldn't be a miracle and would only give a limited speed-up (it was not meant to improve for more than two threads iirc), it was rather to be seen as a first-setp
<Camarade_Tux>
*step
<Proteus_>
Camarade_Tux, oh I know and I guess I'm really not trying to knock them or suggest they failed, I just long for being able to seamlessly take advantage of modern processors. Forking isn't always an option or the best solution, you know?
<Proteus_>
I'd also like to catch up to what F# can do. I'd like more arguments to use ocaml over f# other than vendor lock-in
<Proteus_>
a first step is infinetly better than nothing, of course
<Camarade_Tux>
yeah, sure, the main thing is a difference in point-of-view regarding how to take advantage of several processors
<Proteus_>
I think I read that their implementation allow you to plugin alternative GCs without much hassel. If so, I'm even a little tempted to take a crack at it
<Camarade_Tux>
that was an idea indeed (I don't know if it's done that way but I don't know if it has not be done that way either)
<Proteus_>
Some new or modified bits of the ocaml language might be in order as well, to make multicore programming more natural. Things like specifying a group of threads that need to stay on the same core (though perhaps this could be done with better static code analysis) and all the sync issues that come up. The current thread lib is pretty simplistic compared to other languages.
kelaouchi has joined #ocaml
<Proteus_>
Intel's Threading Building Blocks is looking pretty cool
<Proteus_>
from the wiki: The library consists of data structures and algorithms that allow a programmer to avoid some complications arising from the use of native threading packages such as POSIX threads, Windows threads, or the portable Boost Threads in which individual threads of execution are created, synchronized, and terminated manually. Instead the library abstracts access to the multiple processors by allowing the operations to be treated as "
<Proteus_>
tasks," which are allocated to individual cores dynamically by the library's run-time engine, and by automating efficient use of the cache. This approach groups TBB in a family of solutions for parallel programming aiming to decouple the programming from the particulars of the underlying machine.
<Proteus_>
take that idea and add jocaml and I would never have to leave ocaml.
<im_alone>
the problems that can be solved with trial-and-error are easily parallelizable
<Proteus_>
I'm not sure what you mean by that
<mrvn>
It would be nice to have a List.map (fun input -> worker input) that runs each as thread.
<mrvn>
With a limit of how many in parallel.
<mrvn>
same for all the other no serial functions on lists, arrays, sets, hashtbl, maps, ...
<im_alone>
the genetic algorithms are easily parallelizable
<Proteus_>
or just take advantge of SSE
<mrvn>
im_alone: but then you need to sync the cpus when you breed to genes.
<im_alone>
you can divide N generations to K processors
<Proteus_>
im_alone, a lot of my work revolves around GA, that's not a problem
<Proteus_>
it's the fitness tests that take the horsepower
<Proteus_>
but jocaml would be fine for something like that
<Proteus_>
or just plain fork
<Proteus_>
you don't need communication between any of it until things get pumped back into a database
<Proteus_>
my AI work requires MASSIVE amounts of communication, maxing out memory bandwidth and cpu cycles, which is sort of the opposite end of the spectrum
<im_alone>
Proteus_, GPGPUs
<Proteus_>
preeeeecicely
<Proteus_>
some dissadvantages there too, though
<im_alone>
yes, the hardware market is very reduced
<Proteus_>
though I haven't looked at ATIs work yet
<Proteus_>
reduced?
<im_alone>
e.g., there are not a jukebox of GPGPUs
<im_alone>
there is not know OS ready to manage these GPGPUs
<Proteus_>
well, two competing standards is almost more than enough. Too many options and adoption would be severly restricted: no one is going to rewrite their state of the art game code for 30 different architectures
<Proteus_>
there are also restrictions like being able to have some crazy number of threads per stream processor, but you have to do the same operation for all of them. Which is fine for graphics, but makes some other things a little weird
<Yoric[DT]>
<mrvn> It would be nice to have a List.map (fun input -> worker input) that runs each as thread.
<Yoric[DT]>
With a limit of how many in parallel.
<Yoric[DT]>
There's something like this in SDFlow (shamelessly imported into Batteries Included).
<Yoric[DT]>
It's not implemented with threads but it could be just as well.
<Yoric[DT]>
If you're willing to implement that with threads, I'll be happy to put it into the library.
<im_alone>
Proteus_, hundreds of different soldiers of the same raw has to be processed massively and in parallel, the best soldiers are few of them.
<flux>
mrvn, atleast for map there is one implementation by Harrop ;)
<flux>
but the thing is one wants to make them all communicate with each other somehow
<im_alone>
it has to do algebraic mathematic before of injecting code to the GPGPUs
<flux>
so if you fo pmap (fun x -> pmap (..) x) [..] it still doesn't create more operating system threads than necessary
<Proteus_>
I don't understand why it's so hard (is it?) to make a concurrent garbage collector for ocaml when a bunch of other languages have done it already. Is ocaml special somehow or simply neglected?
<im_alone>
Proteus_, is hard the stop-world of many threads?
<Yoric[DT]>
It's hard in other languages, too.
<Yoric[DT]>
I'm only aware of a few languages with concurrent gcs.
<Proteus_>
I know it's hard, but it's been done
<Yoric[DT]>
JoCaml being one of them.
<mfp>
Proteus_: bunch of languages? which apart, from the JVM and CLR
<Yoric[DT]>
I think there's one for Haskell, but that's quite recent.
<mfp>
Yoric[DT]: AFAIK JoCaml does NOT have a concurrent GC
<Proteus_>
jocaml has a concurrent gc?
<mfp>
neither does GHC
<mfp>
it will merely have a *parallel* GC in 6.10
<Yoric[DT]>
Well, at least, it has a distributed GC.
<Yoric[DT]>
Oh, only parallel?
<Proteus_>
yeah
<Yoric[DT]>
Still, JoCaml has a *distributed* GC.
<mfp>
heh
<im_alone>
i think it's easy, to do a stop-world of many hardware threads is to go to stop-world agent to do a barrier synchronization to stop them
<Yoric[DT]>
(or had, I don't know about the latest versions)
* Yoric[DT]
doesn't understand what im_alone just wrote.
<mfp>
well, if you have several processes (for parallelism), you have several independent GCs for sure
<Proteus_>
im_alone, where are you from?
<im_alone>
i'm from spain
<mfp>
but AFAIK JoCaml's GC is just OCaml's
<Proteus_>
ah
<Proteus_>
mfp, it is
<Yoric[DT]>
I'm certain there is/was a distributed GC for JoCaml.
<Yoric[DT]>
Now, it may be implemented on top of OCaml's.
<mfp>
oh, they might have dropped it in the curr implementation
<Yoric[DT]>
JoCaml's distributed pointers are not necessarily OCaml pointers.
<mfp>
as they did for code mobility
<Yoric[DT]>
Yeah.
<Yoric[DT]>
A shame.
<Proteus_>
my understanding was that jocaml really doesn't add a great deal to ocaml except a few commands that use network sockets or IPC to send work requests and data
<Proteus_>
but I thought it was like a glorified fork command
<Yoric[DT]>
I've toyed a little bit with old-time JoCaml.
<Yoric[DT]>
There was a little bit more to that :)
<mfp>
it adds (a)synchronous channels in the type system and join patterns
<im_alone>
Proteus_, the fork command has a weakness in hw-multithreaded environment
<Yoric[DT]>
Plus these channels are distributed.
<Proteus_>
you have to run instances of jocaml for each processor you want to use
<mfp>
local or remote, they are used the same
<Yoric[DT]>
sure
<mfp>
yup, since there's no concurrent GC...
<mfp>
this could change depending on the results of the OSP
<im_alone>
the new OS post-unix like ready for apps will be a little difficult
<Proteus_>
a concurrent gc + what jocaml offers could make projects like ocsigen really take off
<mfp>
ocsigen with native code = more than fast enough, parallel or not
<flux>
mfp, how about with byte code?
<Proteus_>
yeah, but being able to distribute loads and failures via the join calc would be sweet
<mfp>
flux: AFAICS it's also faster than a normal Rails/PHP solution with bytecode too...
<flux>
although I suppose there's little to gain from running byte code when the dynamically loadable natively compiled modules come
<mfp>
anyway with 3.11 about to be releeased, bytecode = don't care
<flux>
but it's a faster edit-compile-deploy-cycle ;)
<mfp>
yep
<mfp>
*released
<flux>
why bother going native if byte code is fast enough?
<im_alone>
it's need to release a different project from scratch
<Proteus_>
aaah, so it's not so much haskell as it is dropping down to use malloc
<Proteus_>
and yeah, this code is fugly
<im_alone>
the syntax of Haskell is for ogres
<Proteus_>
huh. I thought it was for sadistic college professors
<im_alone>
ocaml can be fastest if all is typed statically
<Proteus_>
but I guess what's even cooler about that benchmark is that the ocaml code is about the same speed but much shorter in length, is readable, and doesn't have to resort to malloc
<im_alone>
and a supreme if it's improved with better burgs
<im_alone>
that target to XMM instructions
<Proteus_>
could you explain your last two statements? I don't follow you
<mrvn>
let pi = 3.141592653589793
<mrvn>
Why is there no module Math?
<Proteus_>
there ought to be
<Proteus_>
or a library of modules, organizing things nicely
<im_alone>
BURG is a known library that search patterns of intermediate code and generate native code
<mrvn>
let n = Array.length bodies - 1 in
<mrvn>
for i = 0 to Array.length bodies - 1 do
<mrvn>
WTF? Why didn't they write n?
jderque has joined #ocaml
<hcarty>
mrvn and Proteus_: There is Extlib, and Yoric[DT] + others are working on extending that with other goodies in Batteries
<mrvn>
hcarty: Extlib is way more than a few math constants if it even has them
<hcarty>
No Math module yet, but the GSL bindings and/or LACAML provide nice math tools
<im_alone>
there is a higher relation between BURG, the scheme of ISA and the modern architecture
<mrvn>
That n-body ocaml code is ugly imperative.
<hcarty>
mrvn: Sorry, the Extlib+Batteries were meant more for Proteus_ re: "or a library of modules, organizing things nicely"
<im_alone>
if the modern architecture is extended then the scheme of ISA has to be extended to gain optimizations
<Proteus_>
hcarty, I'm aware of Batteries, I'm not sure where I was going with that statement actually.
<Proteus_>
are people gravitating towards Batteries or alternatives like Core?
<Yoric[DT]>
I assume Core.
<Yoric[DT]>
However, I'm working on making Batteries (much) more complete than Core.
<Proteus_>
that would be a sweet contribution
lde has quit [Read error: 104 (Connection reset by peer)]
<Yoric[DT]>
At the moment, I'm working on a parser combinator library.
<Yoric[DT]>
(it works but it's going to suffer one large optimization before I release a pre-version)
<Proteus_>
how active is the development? do you have a rough time table for new modules or something like that?
<Yoric[DT]>
Not really.
<Yoric[DT]>
I'm planning to pre-release a few modules in a few weeks.
<im_alone>
find first the trick before of start to write
<Yoric[DT]>
To write what?
<im_alone>
Yoric[DT], there is people that write without tricks
<asmanur>
Yoric[DT]: how do you deal with ocaml's strictness ?
<Proteus_>
Yoric[DT], how would you rate the quality of the Core modules?
<Yoric[DT]>
Anyway, I'm just starting to write up a summary of the current state of the library.
<Yoric[DT]>
im_alone: I still don't understand -- quieres tratar en castellano?
<asmanur>
I wrote a simple parser combinator library, once, and I had to use Lazy to get it work :/
<Yoric[DT]>
asmanur: I don't quite understand the question
<Yoric[DT]>
Proteus_: one second :)
<Proteus_>
:-)
<asmanur>
hum, ocaml does not like recursive definitions of values that are not functions
<Yoric[DT]>
asmanur: I'm not quite sure where strictness would come into play.
<im_alone>
Yoric[DT], hay gente que escribe cosas sin saber buenas pistas
<Yoric[DT]>
asmanur: yeah, that's annoying. Not fatal but annoying.
<Yoric[DT]>
Proteus_: I only looked briefly. The code I saw looked good but it didn't look very consistent to me.
<Yoric[DT]>
Otoh, I only looked *briefly*.
<Proteus_>
Yoric[DT], what sort of breadth are you aiming for with Batteries? something the size of the C++ stlib or boost? something small and elegant?
<Yoric[DT]>
Something large.
<Yoric[DT]>
But let me add something: I see Extlib as something remaining small and elegant and Batteries Included as something much more comprehensive.
<Yoric[DT]>
Batteries Included is meant to be a super-library, consisting in several existing libraries repackaged.
<Yoric[DT]>
It just happens so that I'm adding stuff to the Extlib side for the moment.
<Yoric[DT]>
But the next step will be incorporating ocamlnet.
<Yoric[DT]>
Hopefully, who knows, Batteries Included would be something as large and bloated as the JDK:)
<Proteus_>
a complete graph library would be nice
<Proteus_>
hahaha, hopefully not something that unnavigable
<Yoric[DT]>
Batteries has a structure inspired from the JDK.
<Proteus_>
what's the attraction?
<Yoric[DT]>
e.g. Batlib.System.Sys
<Yoric[DT]>
(= OCaml's Sys module)
<Yoric[DT]>
Batlib.Containers.Enum
<Yoric[DT]>
etc.
<Proteus_>
hrmm
<Yoric[DT]>
The attraction is that we already have too many modules.
<Yoric[DT]>
Now, we need a little bit of order.
<Proteus_>
definitely
<mfp>
Batlib... funny
<mfp>
-> Batcar
<Yoric[DT]>
Yep:)
<mfp>
Battlib is less common according to google
<Proteus_>
It would be nice having coherent documentation going over each algorithm, giving costs and common usage
<Yoric[DT]>
That would be nice.
<Yoric[DT]>
If you're willing to contribute, feel free to do so :)
<Proteus_>
I might just do that. we'll see.
<mfp>
ah I see, a double reverse pun -> "Batlib: my other module is a car"
<Yoric[DT]>
Er...
<Yoric[DT]>
Sure :)
<Yoric[DT]>
Exactly what I had in mind.
<Proteus_>
I like the professionalism and completeness of a library like Boost - that's the sort of thing that would really ease/encourage the usage/adoption of ocaml
<Yoric[DT]>
I'll post something about Batteries in a few hours.
<Proteus_>
cool
<mfp>
hmm the OCaml entries in the shootout are not very optimized, it didn't take me too long to make mandelbrot 20% faster or so
<mfp>
submitting it might prove harder :P
<Proteus_>
mfp, what did you do?
<Associat0r>
I love boost
<mfp>
Proteus_: get rid of the raise Exit, remove some extra indirections
<mrvn>
mfp: implement SOI (single orbital iteration)
lde has joined #ocaml
<mrvn>
OCaml entry for mandelbrot
<mfp>
huh?
<mrvn>
mfp: Instead of iterating a singl pixel you take a region. You put 9 pixel in a grid over it and 4 pixels in the middle of the grid fields for checking. Iterate the 13 pixels and check that interpolating the 4 check pixels is near the real 4 check pixel. If not subdivide and try again.
<mfp>
ah, I don't think the shootout allows such kind of algo changes
<mfp>
is the mandelbrot set convex?
<mrvn>
The result may differ slightly but with the right limit it is near enough.
<mfp>
duh of course not
<mrvn>
On my C64 generating even a 160x200 picture of the M-Set took hours.
<mrvn>
./foo 1280 > foo.ppm 1.24s user 0.01s system 99% cpu 1.248 total
<flux>
btw, xaos is a cool piece of software if you haven't tried it
<mrvn>
flux: doesn't support arbitrary precision so you hit the end of the zoom way to quick.
<flux>
true
<flux>
but you can increase the depth interactively
<flux>
but I suppose up to a limit
<flux>
(I don't know what it actually does when you do that)
<mrvn>
if you change the max iter it recomputes the image.
<mfp>
Yoric[DT]: "Printf and channels are on their way out" -> what will replace the former, functional unparsing? as for the latter, ocamlnet-like IO classes?
<Camarade_Tux>
argh, Proteus_, you stole my sentence ! anyway, it's really impressive, several times I had troubles believing I was not already at the bottom of the page yet :)
Snark has quit ["Ex-Chat"]
asmanur has quit [Remote closed the connection]
<Yoric[DT]>
mfp: I should rephrase that.
<Yoric[DT]>
*module* Printf is on the way out
<Yoric[DT]>
We now have a better implementation of *function* printf.
<Yoric[DT]>
As for the latter, ExtLib has both ocamlnet-like IO classes and [input] and ['a output] which are more generic versions of [channel_in] and [channel_out].
* Yoric[DT]
will be afk now.
<mfp>
hmm vect.ml(i) and rope.ml(i), I recognize that code :)
yziquel has left #ocaml []
ttamttam has joined #ocaml
maattd has quit [Remote closed the connection]
ttamttam has left #ocaml []
psnively has quit []
Proteus has joined #ocaml
Proteus_ has quit [Read error: 104 (Connection reset by peer)]
<bluestorm>
Yoric[DT]: what's the difference between Stream and Enum ?
<bluestorm>
heh
<bluestorm>
should have read the "What's in store" part before asking :p
guillem_ has joined #ocaml
<Yoric[DT]>
:)
<bluestorm>
(printf going away ? wtf ?)
<Yoric[DT]>
bluestorm: essentially, 1) Enums can be cloned 2) Enums can be built from anything.
<Yoric[DT]>
And it's the Printf module, not the printf function.
<Yoric[DT]>
IO.printf is more generic than Printf
<flux>
sprintf, ksprintf?
<Yoric[DT]>
(although obtaining [sprintf] is more tricky for the moment -- I'll try and improve that)
<Yoric[DT]>
I have ideas regarding a way of implementing sprintf.
<Yoric[DT]>
(once you have sprintf, ksprintf should be rather easy)
<Yoric[DT]>
I think it's essentially the matter of putting back stuff I optimized away, actually.
<flux>
google is fast, your article on batteries is on it
<Camarade_Tux>
google is evil : they learned I usually searched ocaml stuff and now when I search for a C thing, I get ocaml results, :evil:
<Yoric[DT]>
:)
<flux>
meh, you need to pass an output to printf always ;)
<flux>
but, off to sleep
rwmjones has joined #ocaml
Camarade_Tux_ has joined #ocaml
Amorphous has quit ["shutdown"]
Amorphous has joined #ocaml
Camarade_Tux has quit [Read error: 110 (Connection timed out)]
<Eridius>
ah, silly me, I checked out the ocaml subreddit
<mfp>
ocaml-bitstring struggled to get +1 yesterday :P
<mbishop>
ocaml? upvoted? IMPOSSIBLE
<mbishop>
most people just assume everything ocaml is from jon harrop and vote it all down :|
<mfp>
maybe this is changing? I was presently surprised a couple times recently.
<Eridius>
who's jon harrop?
<mbishop>
a few of my reddit submissions involving ocaml got upvoted, but it's rare
<mfp>
it's not anything near Haskell, of course
<Eridius>
btw, the name "Batlib" sounds very strange
<mbishop>
well the difference between haskell and ocaml is that haskell has dons, who advertises haskell all the time, but people don't think of him as a troll
<mbishop>
and ocaml has jdh30, who advertises ocaml, but everyone thinks of him as a troll
<Myoma>
and haskell is lazy !
<bluestorm>
i think it's more to see with being pure
<bluestorm>
because you know
<bluestorm>
"pure" sounds like cool
Yoric[DT] has quit ["Ex-Chat"]
<bluestorm>
and it's definitely cool
<mbishop>
I'm not into the whole purity thing
<mfp>
mbishop: well, jdh30 *is* one; dons is just pushing Haskell all the time, but he won't go pick up fights on c.lang.lisp
ido_ has joined #ocaml
<bluestorm>
and you can also say "monad" and then you're a hot shot
<Eridius>
hrm, testing the configuration for godi-mysql fails, part of the output says "see t.log for details", but I don't see a t.log
ido_ has quit [Client Quit]
jeddhaberstro has quit []
<mbishop>
until we have machines that don't operate on side effects, I don't see why I should have to struggle through a language that makes me hide them
<Eridius>
haskell seems very cool, but I'm just not willing to sink a bunch of time and effort into an impractical language
<bluestorm>
mbishop: because side effects are not that great actually
<Myoma>
Eridius: Haskell is practical, just look at darcs! :p
<Eridius>
haha
<bluestorm>
and when you need side effects, explaining it to the type system can be a good idea
<mfp>
I've done little Haskell, but it seems to me it's still too easy to fall into a performance pit
<bluestorm>
yes, that's because of lazy evaluation
<Eridius>
one of the reasons I'm interested in OCaml is because of the performance
asmanur has joined #ocaml
<mfp>
bluestorm: not only that, I mean also things like [Char]. All the string functions are fine until you want any sort of performance. No problem, switch to ByteString, fine. Then you do stuff that requires random access. No problem again, just choose one out of the 5? array libraries.
<bluestorm>
ah, well
<mfp>
you end up having to use lots of small libs because the base types aren't efficient
<bluestorm>
that's the same with python
<mfp>
and then, in a very static-FP style, you have problems when each lib uses its own data type and you want to combine them
<bluestorm>
except they keep the base types :-'
<mfp>
"oh, this lib takes a [Char], but I have a ByteString" -> argh unpack, defeating the point of ByteString
<mfp>
or use foo-bytestring (yet another lib yay)
<bluestorm>
:p
<mfp>
there were like 6 or so regexp libs in the Haskell platform proposal (!)
<Myoma>
lazy evaluation is very interesting because any intuitions you have from strict languages are wrong
<Myoma>
it's a problem when everyone misuses old terminology to describe new things though
<mfp>
oops, not the platform but hackage
<mfp>
the Haskell platform only includes 3 haha
<Myoma>
is there anything about printing infix operators?
<Myoma>
including associativities and such
<Eridius>
I actually found a Monad tutorial using OCaml that I read yesterday to be a lot more illuminating than any of the Haskell-based Monad tutorials I read
<bluestorm>
monads tend to get "more illuminating" each time you read a tutorial
<Eridius>
heh
<bluestorm>
i'd say "regardless of the quality", wich is of course unfair but
<Eridius>
well, yesterday I tried to get a handle on monads again, so I read a few haskell-based tutorials and skimmed the wikipedia page. Reading that OCaml Monad tutorial made a lot more sense, though
<bluestorm>
Eridius: it's an OCaml derivative specialized in XML work
<Eridius>
ok
<bluestorm>
they have a xml-friendly type system iirc
<bluestorm>
and i guess there is binary compatibility
<bluestorm>
so you can use OCamlDuce code as a part of an OCaml program
bluestorm has quit [Remote closed the connection]
itouch has joined #ocaml
<Eridius>
wtf? lwt just failed to install because ocamlfind says it's already installed
<Eridius>
of course, ocamlfind says the installed lwt is 0.1
<Eridius>
grr, I can't figure out any way to find out why this lwt is installed
psnively has joined #ocaml
psnively has quit [Remote closed the connection]
psnively has joined #ocaml
<Eridius>
damnit, found it. apps-ocsigen includes it
<Eridius>
bah
<Eridius>
when they extracted lwt from ocsigen, I'm surprised they didn't update ocsigen to depend on the lwt package
jeddhaberstro has joined #ocaml
marmotine has joined #ocaml
itouch has quit [Remote closed the connection]
Amorphous has quit [Read error: 110 (Connection timed out)]
rwmjones has quit ["Closed connection"]
Amorphous has joined #ocaml
_y_ has joined #ocaml
<_y_>
wow, an actual OCaml IRC channel ... awesome ... can somebody please point me in the direction of a good example of interfacing with C, in which the C function creates and returns a member of a structured/recursively-defined datatype (e.g. an AST)?
hkBst has quit [Read error: 104 (Connection reset by peer)]
<mfp>
_y_: (rule 3) -> a C function equivalent to let bar v1 v2 v3 = Foo (v1, v2, v3) (the tag for the Foo constructor being 0 in the example)
<_y_>
hrmmm ok, so I suppose if I have something like type blah = Foo of int | Bar of string, Foo and Bar will have their own tags ... how do I know which tag corresponds to which type?
<mfp>
_y_: IIRC it's also explained in that chapter (read carefully :). The first constructor has got type 0, the second 1 and so on.
Asmadeus has quit ["nightynight"]
<_y_>
not sure the latter part is correct, upon further reading -- "Tuples are represented by pointers to blocks, with tag 0"
<mfp>
the "tag namespace" of constant and non-constant constructors in separate (so if you have type blah = Foo | Foo of int, the first is represented as the '0' integer, and the second as a block with tag 0)
<mfp>
tuples behave like sum types with only 1 constructor
<mfp>
so type a = (int * int) and type a = Foo of int * int have the same representation, a block with 2 slots and tag 0
<_y_>
ok ... looks like I have some serious digging to do
<_y_>
thanks for pointing me in the right direction
<mfp>
_y_: chapter 18 of the ref manual has got nearly everything you need to know, you just need to read carefully ;)