__DL__ changed the topic of #ocaml to: OCaml 3.09.0 available! Archive of Caml Weekly News: http://sardes.inrialpes.fr/~aschmitt/cwn/ | A free book: http://cristal.inria.fr/~remy/cours/appsem/ | Mailing List: http://caml.inria.fr/bin/wilma/caml-list/ | Cookbook: http://pleac.sourceforge.net/
pmdboi has quit ["Leaving"]
Raziel has quit ["Yo soy goma. Tú eres cola."]
_fab has quit [Remote closed the connection]
Nutssh has quit ["Client exiting"]
Snark has quit ["Parti"]
tom_p has quit [Read error: 110 (Connection timed out)]
batdog is now known as batdog|gone
tom_p has joined #ocaml
Raziel has joined #ocaml
batdog|gone is now known as batdog
<dylan> would it be bad to use one thread per connection for some kind of chat server?
<Smerdyakov> No, especially if you use light-weight threads.
<Smerdyakov> In Concurrent ML, it's not even bad to use one thread per object that will be accessed from multiple threads, because threads are so cheap.
<dylan> -vmthread?
<Smerdyakov> I don't know about OCaml threading. I know that Concurrent ML threads in SML/NJ qualify.
<dylan> well, that's neat. Sort of like Erlang, I suppose?
<Smerdyakov> Yes.
* Smerdyakov has to leave now.
<dylan> I know creating three threads that all do Event.poll in loop will make my system very slow...
joshcryer has joined #ocaml
ski has joined #ocaml
pango_ has joined #ocaml
<Smerdyakov> Why would you want to use polling?
<dylan> I dunno
<dylan> I just was. :)
<Smerdyakov> Doing Event.poll in a one-thread loop doesn't make your system very slow?
<dylan> it does.
<Smerdyakov> OK, so it has nothing to do with the weight of threads.
<dylan> ocaml threads are pthreads on linux
<dylan> so, are pthreads light-weight?
<Smerdyakov> Probably not. I'm not sure.
pango has quit [Read error: 110 (Connection timed out)]
<kmagdsick> Under Linux with NPTL, context switches between threads are very fast
<kmagdsick> look at Drepper's paper on NPTL
<kmagdsick> let me look it up for you
systems has joined #ocaml
<kmagdsick> on their test machine in 2002, creating and destroying threads took 20 microseconds per thread
<kmagdsick> Now... using NPTL, pthreads are kernel threads
<kmagdsick> however, it turns out that they were able to speed up kernel threads fast enough that an M on N lightweight pthreads model was actually slower
<kmagdsick> dylan: you there?
<kmagdsick> dylan: in summary: under NPTL, Linux pthreads are not "light weight" in the Solaris lwp sense
<kmagdsick> dylan: but on the other hand, it's my understanding that Linux kernel threads still exhibit faster context switches than Solaris threads
<kmagdsick> dylan: and Linux now has an O(1) scheduler, so an M on N model isn't necessary for scalability
<kmagdsick> dylan: unless you're hitting the system limit for number of kernel threads
systems has left #ocaml []
<kmagdsick> dylan: on x86 if you're running more than 2 billion threads total or more than 8192 threads per process, you'll need some kind of M on N threading system
* Smerdyakov laughs at the idea of 2 billion threads.
* kmagdsick is glad someone is listening
<kmagdsick> Have there been any other languages that target the Ocaml VM?
<Smerdyakov> Moscow ML
<Smerdyakov> (SML)
<kmagdsick> Any idea about the PyPy people?
<Smerdyakov> I have no idea about anything.
<kmagdsick> anyway, this talk of threads reminds me of the sad state of threads in Python and Ruby
<kmagdsick> a blocking C call will block all threads in Python (cPython) or Ruby
<kmagdsick> at least in Python, gtk_main is a blocking C call
<kmagdsick> which means you can't really do multithreaded gtk programs in Python
<kmagdsick> on the other hand, Ruby does use the Ocaml 31-bit int/ tagged pointer trick
<Smerdyakov> What does that have to do with it?
<kmagdsick> Well, it's a somewhat redeeming point
<Smerdyakov> You mean in comparison to using boxed integers?
<kmagdsick> right
<Smerdyakov> There's no excuse for not having unboxed, full-width integers these days.
<kmagdsick> in statically typed languages?
<Smerdyakov> Yup, and what else would you want to use? ;)
vezenchio has quit ["\\o hutari ga kitto deaeru you na mahou wo kakete - ryoute wo sotto kasanete hora! hohoemu kara - hontou no kimoti kidukanai ]
<kmagdsick> It's too bad more languages don't use type inferencing
joshcryer has quit []
<kmagdsick> you get most of the advantages of dynamic typing
<kmagdsick> with all of the advantages of static typing
<vincenz> hello
<kmagdsick> hello
<KrispyKringle> Not to mention type polymorphism.
<KrispyKringle> Dynamic typing allows much of the same style, minus the safety.
<KrispyKringle> Or, polymorphic types with typeclasses allow pretty much everything you might want with dynamic typing, only with compile time type checking.
<KrispyKringle> And PyPy is Python implemented in Python. Why would they target the OCaml VM?
<kmagdsick> PyPy targets several VMs
<kmagdsick> give me a second and I can list a few for you
<KrispyKringle> oh, really?
<KrispyKringle> I thought they were just aiming for Python.
<kmagdsick> hrm... well maybe it's all through C
<kmagdsick> but that makes me wonder why they use llvm
<KrispyKringle> I don't know much more about them. Their website is pretty sparse. But it only says C and Python.
<kmagdsick> in any case, they write the Python interpreter in a restricted subset of Python
<kmagdsick> called RPython
<KrispyKringle> Did you mean an implementation in OCaml, or an implementation in Python that emits bytecode for the OCaml VM?
<kmagdsick> in any case, they use llvm to generate native code
<kmagdsick> KrispyKringle: an implementation that emits Ocaml bytecode
<KrispyKringle> Hmm. Not familiar with LLVM. Interesting.
<KrispyKringle> Ah
<kmagdsick> LLVM uses a RISC-like SSA bytecode
<kmagdsick> very close to the hardware
<kmagdsick> hence the name Low Level Virtual Machine
<KrispyKringle> ah :P
<kmagdsick> Michael Franz did some interesting work with adding support for a second type of bytecode to the IBM Jikes RVM Java VM
<KrispyKringle> Anyway, I certainly understand the frustration with dynamic typing at time. Python runtime exceptions are often my undoing.
<KrispyKringle> Specifically None type.
<KrispyKringle> I often expect a 0 or an empty list or null string when instead I get a None type. For some reason, it's very unintuitive and I forget to check for it.
<KrispyKringle> Which results in a runtime error, of course.
<kmagdsick> Michael Franz showed significant speed improvements using an SSA-based bytecode rather than a stack-machine-based bytecode
<KrispyKringle> So why'd Java choose the latter?
kmagdsick is now known as kmag|away
batdog is now known as batdog|gone
m3ga has joined #ocaml
Nutssh has joined #ocaml
Skal has joined #ocaml
Schmurtz has quit ["Dodo !"]
revision17_ has joined #ocaml
Revision17 has quit [Read error: 110 (Connection timed out)]
Nutssh has quit ["Client exiting"]
Skal has quit [Remote closed the connection]
Skal has joined #ocaml
Raziel has quit ["Yo soy goma. Tú eres cola."]
Skal has quit [Remote closed the connection]
Skal has joined #ocaml
vodka-goo has joined #ocaml
smimou has joined #ocaml
ramkrsna has joined #ocaml
_exa has joined #ocaml
exa has quit [Read error: 110 (Connection timed out)]
<dylan> thanks kmag|away
ramkrsna has quit [Read error: 110 (Connection timed out)]
Raziel has joined #ocaml
vezenchio has joined #ocaml
Demitar_ has quit ["Terminated with extreme prejudice - dircproxy 1.0.5"]
Demitar has joined #ocaml
xtrigger has joined #ocaml
<xtrigger> anyone here?
<xtrigger> i got a quite simple question since ive been using ocaml for just two weeks now
<xtrigger> how do you assign values to a global variable from a program?
<xtrigger> *from a function
xtrigger has left #ocaml []
ski_ has joined #ocaml
<flux__> let global_variable = ref 42
<flux__> global_variable := 7
<flux__> (later on somewhere)
<flux__> note that the value is accessed with !global_variable
<pango_> he's gone
<flux__> oh :-)
<Demitar> And I think such a response should be accompanied by the usual "global variables are evil" warning. :)
batdog|gone has quit [Remote closed the connection]
batdog|gone has joined #ocaml
kmag|away is now known as kmagdsick
<kmagdsick> KrispyKringle: sorry for the delay
<kmagdsick> KrispyKringle: Java went with a stack-based bytecode because it's simpler if you're going to do strait interpretation and no JIT-ing
<kmagdsick> KrispyKringle: and if you're not going to compress the bytecode, stack-based bytecodes generally take up less room
<kmagdsick> KrispyKringle: remember Java originally was intended to run on everything from 8-bit microprocessors on toasters to big-iron mainframes
<kmagdsick> KrispyKringle: but as it stands, anything wanting to run Java uses at least a 32-bit microcontroller with 8 MB of RAM
<kmagdsick> KrispyKringle: also, Sun went with a stack-based bytecode long before Michael Franz started playing around with the RVM
_fab has joined #ocaml
<KrispyKringle> kmagdsick: Ok. Thanks for the clarification.
<KrispyKringle> I'm reading up on the JVM now as part of a project I'm in. It's a pretty clean architecture, I admit.
Bigb[a]ng is now known as Bigbang
<kmagdsick> KrispyKringle: let me get you some URIs
<kmagdsick> That's for the DIS virtual machine used by Inferno
<kmagdsick> it's a memory-machine based VM, which is an infinite-register representation
<kmagdsick> SSA is also an infinite register representation
<kmagdsick> That paper talks a little bit about how memory-machine bytecodes are better for JIT than stack-machine bytecodes
<KrispyKringle> kmagdsick: Cool. Thanks.
<KrispyKringle> I'll check it out.
<kmagdsick> KrispyKringle: http://citeseer.ist.psu.edu/721276.html <-- this is the most relevant paper that Franz wrote
<kmagdsick> Franz got his doctorate under Wirth, of Pascal fame
rq has quit [Read error: 104 (Connection reset by peer)]
ski_ has quit [Read error: 110 (Connection timed out)]
flux__ has quit [Read error: 110 (Connection timed out)]
flux__ has joined #ocaml
rq has joined #ocaml
flux__ has quit [Read error: 104 (Connection reset by peer)]
flux___ has joined #ocaml
faigo has joined #ocaml
flux___ has quit [Read error: 104 (Connection reset by peer)]
joshcryer has joined #ocaml
flux__ has joined #ocaml
bzzbzz has joined #ocaml
Skal has quit [Remote closed the connection]
bd_ has joined #ocaml
Nutssh has joined #ocaml
_JusSx_ has joined #ocaml
m3ga has quit [Read error: 104 (Connection reset by peer)]
Nutssh has quit ["Client exiting"]
joshcryer has quit [Read error: 104 (Connection reset by peer)]
vodka-goo has quit []
smimou has quit ["bli"]
rq has quit ["Leaving"]
Amorphous has quit ["arg... must... shutdown... computer burnin..."]
joshcryer has joined #ocaml
_JusSx_ has quit ["leaving"]