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>
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