lindril has quit [Read error: 54 (Connection reset by peer)]
lindril has joined #ocaml
Kinners has joined #ocaml
asquii has joined #ocaml
asqui has quit [Read error: 110 (Connection timed out)]
asquii is now known as asqui
graydon has left #ocaml []
gehel has quit ["changing servers"]
gehel has joined #ocaml
skylan has quit [Read error: 60 (Operation timed out)]
skylan has joined #ocaml
Kinners has quit [Read error: 104 (Connection reset by peer)]
mattam has quit [Read error: 60 (Operation timed out)]
lament has joined #ocaml
matkor has quit [Read error: 60 (Operation timed out)]
iusris has left #ocaml []
docelic|sleepo is now known as docelic
uzdav has joined #ocaml
<uzdav>
I have a dual cpu machine running SMP linux (RH 7.2). I configured ocaml with the -with-pthreads option, and built it. When I run my application, I see that a native thread was actually spawned (as two entries show up in "top"). The problem is that they seem to be scheduled on the same CPU, and so the program is not taking advantage of my other CPU, and takes just as long as the non-threaded version. Is there any way to get both CPUs to be us
<uzdav>
ed in parallel?
<emu>
is your application multi-threaded?
<uzdav>
Yes.
<uzdav>
When I run top, I see two entries, both taking 50% of the same CPU. My other CPU remains idle.
<emu>
sounds like a kernel issue to me
<uzdav>
Any idea what I should be looking for?
<uzdav>
Today is the first time I've used ocaml threads, so I'm probably doing something wrong. :)
<uzdav>
But you are saying that it should be possible to get "100%" usage out of both CPUs using ocaml?
<uzdav>
(The documentation isn't very clear about that.)
uzdav has quit [Excess Flood]
uzdav has joined #ocaml
uzdav has quit ["[x]chat"]
uzdav has joined #ocaml
<uzdav>
For anyone interested in my question, I think I found the answer to my thread question. In Xavier's own words:
<uzdav>
In summary: there is no SMP support in OCaml, and it is very very
<uzdav>
unlikely that there will ever be. If you're into parallelism, better
<mrvn>
Isn't that how polymorphic types are shown?
<listener>
Supposedly it has some good debugging techniques.
<mrvn>
mrvn@dual:/tmp/foo% ar -x base-files_3.0.7_mips.deb
<mrvn>
ups
Dalroth has quit []
<listener>
>>>I've just skimmed that paper and it seems to have good techniques. Now I will dig further.
<listener>
mrvn: Part of the trick of Y is to pass the function to itself. Thus the (f f).
<listener>
So obviously you have to have an "undefined" argument.
<mrvn>
listener: no, its not undefined. just not typeable by the normal type engine.
<listener>
Either a recursive type ('a->'a)->'a|(('a->'a)->'a)->'a|....
<mrvn>
To understand why it fails you have to look at how the type engine determines types.
<listener>
Or of type ('x->'a)->'a where x has to be a polymorphic type.
<mrvn>
Also the way types are normaly written (without the as) its just not possible to write the type.
<listener>
I'm not sure what you mean by possible.
<listener>
If you do:
<listener>
type rt=int->rt->int;;
<mrvn>
let f f = f f;; that has at first a type 'a->b' because its a function.
<listener>
Then: let f n (rt h) = if n<2 then 1 else n*(h (n-1) (rt h));;
<listener>
works under OCaml with out -rectypes.
<mrvn>
But it calls "f f" => 'a->('b->'c)
<listener>
Of course rectype is a polymorphic type.
<mrvn>
But it calls "f f" => ('a->'b)->'c I mean
<mrvn>
But 'b is the f that gets called, so it has type 'd->'f
<mrvn>
but 'f is the f that gets called, so it has 'g->'h
<mrvn>
...
<listener>
<mrvn> ...
<listener>
Sorry. Hiccup.
<listener>
Try.
<listener>
type 'a rf = RF of ( 'a rf -> 'a );;
<mrvn>
By defining a recursive type rt you remove the recusion from the type of the function and then it works.
<listener>
let f (RF f) = f (RF f);;
<mrvn>
# let f (RF f) = f (RF f);;
<mrvn>
val f : 'a rf -> 'a = <fun>
<mrvn>
no recursion there anymore.
<listener>
Yes. Something like Y works in Lisp/Scheme because it's...
<listener>
volunarily typed????
<mrvn>
listener: No, lisp and scheme just don't care about the type. They just try and fail.
<mrvn>
(or not if one is lucky)
<listener>
But the typing gets in the way in OCaml (probably Haskell too ). Because they type functions strongly.
<listener>
Is they just had an arbitrary type function, without specifying the argument/return types.
<mrvn>
and gladly so.
<mrvn>
90% of all bugs are type errors.
<kev>
mrvn: it hurts for RAD though
<mrvn>
And that numberis old, from times when people could still programm properly.
<kev>
especially when you're beating stuff out and refactoring it
<listener>
In Lisp you can declare type in function calls. It will also try to infer type, but give up if can't.
<listener>
I wouldn't say 90%. But typing certainly helps.
<mrvn>
kev: I hate untype languages. You develope some source and you try run it and everything works. 3 weeks later while doing something other on the source it suddenly fails.
<mrvn>
Just because the type doesn't match on some rarely used case.
* listener
thinks that people who hate typing just want to make type errors.
<kev>
mrvn: yeah, but they still have their place
<kev>
would be nice to have a python equivalent for ocaml
<iusris>
using untyped languages without good unit testing is a gamble.
<mrvn>
sure, but not for anything complex.
<kev>
that way you can throw your app up, suss it out, then replace it bit by bit with ocaml code
<kev>
much like you can do with python/swig c++ etc
<listener>
For programs less then 500 lines untyped language are probably bettter. Because you can beat the thing to death.
<kev>
yep
<mrvn>
I use ocaml to throw something together and then I think about doing it in C++ for optimisation.
<kev>
ocaml forces you to get it right first time
<kev>
which doesn't really work that great
<mrvn>
you get used to it quite fast
<listener>
Better then spending time trying to figure out where you got it wrong.
<kev>
mrvn: yeah, but for each new situation you write an app for you'll wrestle with the app structure
<mrvn>
Thats my experience too.
<mrvn>
In untyped languages something as simple as a misspelling can throw you off for hours.
<kev>
I'm certainly converted to the batter in python, then port approach atm
<listener>
The only problem is that I'm a Caml newbie. I spend hours getting something to compile, but when it does it usually works.
<mrvn>
listener: thats what ocaml feels like. Once it compiles it usually works.
<kev>
mrvn: how do you find that for real life situations though?
<kev>
ie, changing specs, unexpected parts of specs, etc
<listener>
About ten years ago, Al Stevens the writer of the Dr. Dobbs C/C++ column said that he passed some C code through a C++compiler.
<listener>
It wouldn't compile so he fixed the compiler errors. Then several bugs he could never find went away.
<mrvn>
kev: works fine wih mldonkey.
<kev>
mrvn: mldonkey ain't real life ;)
<kev>
I was meaning more for a business situation or something
<mrvn>
listener: C compiler are pretty loose about all the pointer arithmetic. The C standard allows a much stricter checking on pointers but all compilers ignore those for speed reasons.
<mrvn>
kev: Biggest think I work on atm.
<mrvn>
Gr
<mrvn>
kev: Being a student I have no real business experience yet. Nothing bigger than a few php or pyhon scripts.
<mrvn>
bash ist ja ok
<kev>
mrvn: I find that the real challenge with programming comes with dealing with the open environment
<mrvn>
ups
<mrvn>
ETOOMANYCHATS
<kev>
but then again, it depends on what your job is
<mrvn>
kev: you mean when your coworkers change the datatypes and interfaces on you all the time?
<kev>
mrvn: it's not as much as the programmers, but the other things you need to work with
<listener>
PHBs
<kev>
eg, your company needs to treat client relationships in a different way, and so your interfaces need to change
<kev>
i also have to admit, that I've worked for far too many cowboys ;)
<mrvn>
What I miss most in open source projects is that there is no direction. Everyone does what he feels like and then someone responsible for the repository picks up what looks good.
<kev>
yep, higher level of control in open source really is lacking
<listener>
I've got to go. Thanks for the help.
<listener>
Bye.
<mrvn>
You can't meet in the morning and decide what way to go for the day. morning means when you go to bed for other guys.
listener has quit ["ERC v2.0 (IRC client for Emacs)"]
<kev>
what did the linux developer say to the microsoft developer?
<mrvn>
And if you start a discussion about a certain problem the other guy might be away for a week or something.
<kev>
do you want fries with that?
<mrvn>
Is there a more omplete implementation of the X11 interface for ocaml? I saw Graphics and GraphicsX11 modules. But the X11 variant has only subwindows as extras. Nothing like shared memory, server bitmaps, backing store options etc.