Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Berke Durak]

[-- Attachment #1: Type: text/plain, Size: 5276 bytes --]

On Mon, Apr 21, 2008 at 1:17 PM, Jon Harrop <jon@ffconsultancy.com> wrote:

> Quad cores are already the norm.
>
> An *eight* core Dell Precision T7400 now costs only £1,171. Our desktop
> machines will be replaced with these eight core machines before the end of
> this year.


Well it's worse than what I thought then.


> > I'd hate to see Ocaml become one of the slower languages.
>
> For many applications, that already happened.
>

By slower, I meant something like "not within a factor of 1.5/2 of the top
five fastest languages".
I assume you are referring to parallelizable, number-crunching tasks?

> That way one could embed multiple Ocaml libraries in programs written in
> > other languages (which could allow easier monetization of Ocaml software
>
> There are many other issues that prevent the commercialization of OCaml
> libraries.


That could take care of at least one of those issues.  What are the others?
.NET
interoperability I guess.


> > Also, we could explore alternate paths to paralellism, such as running
> > multiple Ocaml interpreters/runtimes in different threads with disjoint
> > heaps. Those threads would run truly in parallel on different CPUs.
>
> Communication is too slow for that to be useful outside a few niche
> applications.


The problem to be solved here is not throughput, but paralellizability.
Note that bus and cache coherency protocols already do lots of
communication,
but in hardware.  So here you'd have software communication, which would be
quite slower, but your individual processes could run at full speed.

As for the applications, I'm thinking of Ocaml as a web programming language
as
a "niche" were such an approach might be useful.


> > I personally don't believe much in fine-grained parallelism using
> threads
> > and locks because it makes the GC difficult,
>
> This is certainly a difficult problem but you cannot compete without a
> concurrent GC now.


A concurrent GC should be developed.  But I think you can compete in some
"niches"
without a concurrent GC.

Web programming should not be dismissed as a lowly art anymore - and even if
it is lowly,
it is quite lucrative.

Look at Ruby, basically a disguised functional language with a
monkey-patchable object system.
Web developers embraced it extremely quickly.  And while web developers, on
average, are
not bright programmers (or programmers at all), their huge population means
that there is a sizable
portion of the brighter and brightest programmers that do "web developing" -
be it front-end or
back-end.  Do I need to remind everyone that the web is the most important
technological development
in the last twenty years?

Now data center owners love Ruby-based apps, since you need 60 servers to do
300 requests/second.
So Ruby is not the fastest language on Earth - it was second-to-last on the
latest Alioth shootout.
And people are slightly starting to get disillusioned with Ruby, mostly for
performance reasons,
and migrating to Python.  Note that neither of those languages have good
parallelism support nor are
especially fast.

So Ruby and Python, which are slow and do not have concurrent GCs, let alone
a half-decent type system,
enjoyed widespread adoption.  Why?  And can Ocaml do the same?

I think dynamic typing and the metareflexive capabilities are not the reason
behind Python and Ruby's success.
Nor is embeddability.  The main reason, I think, is absent/automatic/easy
compilation.

Compilation and linking are extremely painful things, especially when you
want to start to learn a new language
in good faith.  Java has a relatively good packaging/loading model which is
part of its success.  Ocaml is
terrible at this.

Yet, unlike Javascript or PHP, Python and Ruby are system programming
languages, in which you can write
command-line tools or a small HTTP server without needing a Java runtime
with a RSS of 300MB .  As is Ocaml.

Also, Ruby and Python smell neither Sun nor Microsoft Enterpriseiness.  They
are 100% FOSS-compatible.  As is Ocaml,
unlike F#.  Java is going a long way with OpenJDK, but it's still not
FOSS-kosher.

This means that there is a gap to fill - people already understood that
closures are useful,
they are starting to realize that higher-order functions are useful too and
that without static typing,
their applications become unmaintainable and they can't cooperate
effectively.

Scala or Groovy won't fill it because they are not natives in JVM-land and
they have the unremovable
Java-enterprise stench.

Erlang may be scalable but is not general-purpose and people hate to learn
extra languages.

Haskell won't fill that niche either, because if *I*'m not ready to wrestle
with monads to get some type-theoretical
effect safety (only to start peppering my code with unsafePerformIO and
strictness annotations), then the average
developer certainly won't be.

So there is a gap to be filled, and Ocaml could be the next fashionable web
programming language if we fix
a few things or two:
- Compilation and package headache,
- Missing batteries.

If someone manages to write a good concurrent GC it'll be quite nice.
Meanwhile, I see heap-disjoint
parallelism as a low hanging fruit.

I think the market is ripening for such an offer.  But the gap is closing.
We must hurry!
-- 
Berke

[-- Attachment #2: Type: text/html, Size: 6771 bytes --]

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Richard Jones]

On Mon, Apr 21, 2008 at 02:27:36PM +0200, Berke Durak wrote:
> On Mon, Apr 21, 2008 at 1:17 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> > Quad cores are already the norm.
> >
> > An *eight* core Dell Precision T7400 now costs only £1,171. Our desktop
> > machines will be replaced with these eight core machines before the end of
> > this year.
> 
> Well it's worse than what I thought then.

Your threaded code is going to look really stupid when you have NUMA
machines with dozens of cores.  Why are we optimizing for a case (SMP)
which will only be around for a few years.  Arguably SMP isn't even
around now ... the AMD machine on which I'm typing this is firmly NUMA
with a good 10% penalty for accessing memory owned by the other
socket.

> A concurrent GC should be developed.  But I think you can compete in
> some "niches" without a concurrent GC.

Why should a concurrent GC be developed?  Threaded code is a nightmare
to write & debug, and it's only convenient for lazy programmers who
can't be bothered to think in advance about how they want to share
data.  OCaml supports fork, event channels & shared memory right now
(and has done for years) so there is no penalty to writing it
properly.

[...]
> Compilation and linking are extremely painful things, especially when you
> want to start to learn a new language
> in good faith.  Java has a relatively good packaging/loading model which is
> part of its success.  Ocaml is
> terrible at this.

Huh?  OCaml scripts work perfectly well, they're compiled when you run
them.  I use them all the time.

[...]
> So there is a gap to be filled, and Ocaml could be the next fashionable web
> programming language if we fix
> a few things or two:
> - Compilation and package headache,
> - Missing batteries.

What distro are you using?  Obviously one where you can't just
apt-get / yum install / godi whatever all the libraries and support
software you need.  There is no "package headache" over in Debian /
Fedora / GODI at all.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Berke Durak]

[-- Attachment #1: Type: text/plain, Size: 3156 bytes --]

On Mon, Apr 21, 2008 at 3:11 PM, Richard Jones <rich@annexia.org> wrote:

> Your threaded code is going to look really stupid when you have NUMA
> machines with dozens of cores.  Why are we optimizing for a case (SMP)
> which will only be around for a few years.  Arguably SMP isn't even
> around now ... the AMD machine on which I'm typing this is firmly NUMA
> with a good 10% penalty for accessing memory owned by the other
> socket.


Yes, that's why some of us don't buy too much shares in semaphore factories.

> A concurrent GC should be developed.  But I think you can compete in
> some "niches" without a concurrent GC.

Why should a concurrent GC be developed?  Threaded code is a nightmare
> to write & debug, and it's only convenient for lazy programmers who
> can't be bothered to think in advance about how they want to share
> data.  OCaml supports fork, event channels & shared memory right now
> (and has done for years) so there is no penalty to writing it
> properly.


Why not?  Let's be conciliant.  If people want to develop a concurrent GC,
let them have a try.  BTW I'm not a thread guy - I don't like POSIX threads
very much.  I really appreciate Lwt and use my monadic threads when
developing
my own stuff.

> Compilation and linking are extremely painful things, especially when you
> > want to start to learn a new language
> > in good faith.  Java has a relatively good packaging/loading model which
> is
> > part of its success.  Ocaml is
> > terrible at this.
>
> Huh?  OCaml scripts work perfectly well, they're compiled when you run
> them.  I use them all the time.


Yes, while I don't use them, Ocamlscripts are certainly nice thing, thank
you for that.
Compiling an Ocaml program remains quite an involved task, with all those
not very
inspectable cma, cmx, cmi, cmo, dll.so and cmxas floating around (cmigrep
helps a lot) with
their C flags and DLL lists.  It gets even more complicated when you need to
use
native code or preprocessors.  Ocamlfind helps a bit, ocamlbuild a bit more,
but
it's still painful.

In Java, if you don't use native code, you just make a jar and ship the
classes: jar cf foo.jar foo/,
upload, java -jar foo.jar.

[...]
> > So there is a gap to be filled, and Ocaml could be the next fashionable
> web
> > programming language if we fix
> > a few things or two:
> > - Compilation and package headache,
> > - Missing batteries.
>
> What distro are you using?  Obviously one where you can't just
> apt-get / yum install / godi whatever all the libraries and support
> software you need.  There is no "package headache" over in Debian /
> Fedora / GODI at all.


I'm not talking of packages in general - I'm using Godi on Debian and
Ubuntu,
but I'm talking about packaging Ocaml libs during development time.
We need an easy-to-use lightweight packaging mechanism for developers and
that has
been discussed many times on this list.  Godi is more or less OK when you
passively
use libraries, but it's non-trivial to inject your own stuff (even if it's
just for yourself).
Let's not start ye olde package management thread again. The fact is that
there is
large room for improvement :)

-- 
Berke

[-- Attachment #2: Type: text/html, Size: 4304 bytes --]

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Jon Harrop]

On Monday 21 April 2008 14:11:51 Richard Jones wrote:
> On Mon, Apr 21, 2008 at 02:27:36PM +0200, Berke Durak wrote:
> > On Mon, Apr 21, 2008 at 1:17 PM, Jon Harrop <jon@ffconsultancy.com> wrote:
> > > Quad cores are already the norm.
> > >
> > > An *eight* core Dell Precision T7400 now costs only £1,171. Our desktop
> > > machines will be replaced with these eight core machines before the end
> > > of this year.
> >
> > Well it's worse than what I thought then.
>
> Your threaded code is going to look really stupid when you have NUMA
> machines with dozens of cores.  Why are we optimizing for a case (SMP)
> which will only be around for a few years.  Arguably SMP isn't even
> around now ... the AMD machine on which I'm typing this is firmly NUMA
> with a good 10% penalty for accessing memory owned by the other
> socket.

10% is nothing compared to the orders of magnitude cost of message passing.

> > A concurrent GC should be developed.  But I think you can compete in
> > some "niches" without a concurrent GC.
>
> Why should a concurrent GC be developed?  Threaded code is a nightmare
> to write & debug, and it's only convenient for lazy programmers who
> can't be bothered to think in advance about how they want to share
> data.  OCaml supports fork, event channels & shared memory right now
> (and has done for years) so there is no penalty to writing it
> properly.

Ten years ago that was:

  "Why should we use gargage collection? Garbage collectors are a nightmare to 
implement and debug and are only useful for lazy programmers who cannot be 
bothered to deallocate values themselves. C++ has reference counting right 
now and there is no penalty for using it properly."

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Dario Teixeira]

Hi,

> Now data center owners love Ruby-based apps, since you need 60 servers to do
> 300 requests/second.

Is this hyperbole or hard numbers?  Since I finally managed to use natdynlink
on an AMD64 machine (see Alain Frisch's today's message to this list), I ran
some simple benchmarks on a dummy Ocsigen application generating dynamic pages.
The results were more than good enough for my purposes, though I can't really
compare them with other languages/frameworks:

http://nleyten.com/2008/04/21/simple-benchmarks-on-the-ocsigen-server.aspx

Could Ocsigen be a killer app for Ocaml?  Should we think of setting up
a simple "web framework shootout"?  (Though personally I think the
advantages of Ocsigen go way beyond speed).

Cheers,
Dario Teixeira



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Berke Durak]

Dario Teixeira wrote:
> Hi,
> 
>> Now data center owners love Ruby-based apps, since you need 60 servers to do
>> 300 requests/second.
> 
> Is this hyperbole or hard numbers?  Since I finally managed to use natdynlink
> on an AMD64 machine (see Alain Frisch's today's message to this list), I ran
> some simple benchmarks on a dummy Ocsigen application generating dynamic pages.
> 

Hello,

Well I'll say that it's hyperbole to be on the safe side, but you might want to
look at this:

   http://highscalability.com/friends-sale-architecture-300-million-page-view-month-facebook-ror-app

Some people say that it's a Rails problem but why has Ruby the place it has
on the shootout?  Can't they indulge in some malloc+pointer-arithmetic tricks
like our Haskell brothers :) ?

> The results were more than good enough for my purposes, though I can't really
> compare them with other languages/frameworks:
>
> http://nleyten.com/2008/04/21/simple-benchmarks-on-the-ocsigen-server.aspx

Well these are pretty good numbers IMHO.  My own monadically threaded homegrown
"framework" tops at about 300 reqs/seq at ronchonneuse.com (native code,
a Dedibox on a VIA Esther at 2GHz), and it goes thru Lighttpd via SCGI
(FastCGI should improve it but it's not worth the hassle for now.)

> Could Ocsigen be a killer app for Ocaml?  Should we think of setting up
> a simple "web framework shootout"?  (Though personally I think the
> advantages of Ocsigen go way beyond speed).

Could be, but not in bytecode.  Let's place our hopes in natdynlink!

-- 
Berke DURAK

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Elliott Oti]

Richard Jones wrote:
> OCaml supports fork, event channels & shared memory right now
> (and has done for years) so there is no penalty to writing it
> properly.
>   
Not on Win32. I use Solaris at work and Linux at home, but Win32 is a 
big platform - the biggest there is right now - and the Unix module 
process- and signal-related implementations there are unusable.

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Richard Jones]

On Mon, Apr 21, 2008 at 03:44:08PM +0100, Jon Harrop wrote:
> On Monday 21 April 2008 14:11:51 Richard Jones wrote:
> > Your threaded code is going to look really stupid when you have NUMA
> > machines with dozens of cores.  Why are we optimizing for a case (SMP)
> > which will only be around for a few years.  Arguably SMP isn't even
> > around now ... the AMD machine on which I'm typing this is firmly NUMA
> > with a good 10% penalty for accessing memory owned by the other
> > socket.
> 
> 10% is nothing compared to the orders of magnitude cost of message passing.

Or you could use shared memory (as I said below).  How do you think
shared memory works in a NUMA machine anyway?

> > > A concurrent GC should be developed.  But I think you can compete in
> > > some "niches" without a concurrent GC.
> >
> > Why should a concurrent GC be developed?  Threaded code is a nightmare
> > to write & debug, and it's only convenient for lazy programmers who
> > can't be bothered to think in advance about how they want to share
> > data.  OCaml supports fork, event channels & shared memory right now
> > (and has done for years) so there is no penalty to writing it
> > properly.
> 
> Ten years ago that was:
> 
>   "Why should we use gargage collection? Garbage collectors are a nightmare to 
> implement and debug and are only useful for lazy programmers who cannot be 
> bothered to deallocate values themselves. C++ has reference counting right 
> now and there is no penalty for using it properly."

Thanks for the straw man argument there.  Garbage collectors and _not_
using threads both improve the safety of the language.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Richard Jones]

On Mon, Apr 21, 2008 at 06:26:54PM +0200, Elliott Oti wrote:
> Richard Jones wrote:
> >OCaml supports fork, event channels & shared memory right now
> >(and has done for years) so there is no penalty to writing it
> >properly.
> >  
> Not on Win32. I use Solaris at work and Linux at home, but Win32 is a 
> big platform - the biggest there is right now - and the Unix module 
> process- and signal-related implementations there are unusable.

Windows has plenty of problems, starting with how much it costs and
how little you get for your money.  If we start to design everything
based on the worst platform out there then it's just a race to the
bottom.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Jon Harrop]

On Monday 21 April 2008 21:48:26 Richard Jones wrote:
> On Mon, Apr 21, 2008 at 06:26:54PM +0200, Elliott Oti wrote:
> > Richard Jones wrote:
> > >OCaml supports fork, event channels & shared memory right now
> > >(and has done for years) so there is no penalty to writing it
> > >properly.
> >
> > Not on Win32. I use Solaris at work and Linux at home, but Win32 is a
> > big platform - the biggest there is right now - and the Unix module
> > process- and signal-related implementations there are unusable.
>
> Windows has plenty of problems, starting with how much it costs and
> how little you get for your money.  If we start to design everything
> based on the worst platform out there then it's just a race to the
> bottom.

As much as you may personally hate Windows, it does have implementations of 
enabling technologies like .NET that are far in advance of anything available 
on any other platform. If Mono were anything like as good as .NET then 
implementing a modern ML would be vastly easier.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Arnaud Spiwack]

> Thanks for the straw man argument there.  Garbage collectors and _not_
> using threads both improve the safety of the language.
>   
This might depend on what kind of thread interface you are provided 
with. Of course it's never easy to work with non-determinism, but if I 
take jocaml for instance, which gives you a process (in the sense of 
pi-calculus) interface to threads, and it makes it probably rather safe 
actually, possibly stronger safety when dealing with multiple processes 
(or UI threads possibly) than doing things with low-level primitves like 
fork and such.

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Berke Durak]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

Richard Jones:
> Garbage collectors and _not_ using threads both improve the safety of the
language.

Arnaud Spiwack:

> This might depend on what kind of thread interface you are provided with.
> Of course it's never easy to work with non-determinism, but if I take jocaml
> for instance, which gives you a process (in the sense of pi-calculus)
> interface to threads, and it makes it probably rather safe actually,
> possibly stronger safety when dealing with multiple processes (or UI threads
> possibly) than doing things with low-level primitves like fork and such.
>

That's the point.  The conventional threading model (mutable shared data and
mutexland) is unsafe by default.  It's like the good old days of manual
memory management in C, except
that you replace malloc/free with pthread_mutex_lock/pthread_mutex_unlock
and
signal 11 by deadlocks.

But it's actually worse because mutexing doesn't compose as well as malloc.
This means that it's difficult to increase the abstraction level.
-- 
Berke

[-- Attachment #2: Type: text/html, Size: 1313 bytes --]

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Jon Harrop]

On Monday 21 April 2008 22:16:49 Berke Durak wrote:
> That's the point.  The conventional threading model (mutable shared data
> and mutexland) is unsafe by default.  It's like the good old days of manual
> memory management in C, except that you replace malloc/free with
> pthread_mutex_lock/pthread_mutex_unlock and signal 11 by deadlocks.

That is not "unsafe" in the conventional sense but it is a potential problem. 
The severity is due to difficulty of debugging (which .NET and Visual Studio 
actually handle extremely well) rather than this being a common problem.

> But it's actually worse because mutexing doesn't compose as well as malloc.
> This means that it's difficult to increase the abstraction level.

I disagree. Locks are a problem in mainstream software because mutation is 
everywhere so many locks are required and the rats nest of dependencies is 
unmaintainable. However, this is not the case in functional languages where 
mutation is only found in performance-critical sections. Our 250kLOC 
visualization code base required only 4 locks in the entire library to 
parallelize it. Maintaining the dependencies between these locks is trivial 
on the scale of things.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] The closing gap (warning: long, inflammatory rant)

[Jon Harrop]

On Monday 21 April 2008 21:47:21 Richard Jones wrote:
> On Mon, Apr 21, 2008 at 03:44:08PM +0100, Jon Harrop wrote:
> > On Monday 21 April 2008 14:11:51 Richard Jones wrote:
> > > Your threaded code is going to look really stupid when you have NUMA
> > > machines with dozens of cores.  Why are we optimizing for a case (SMP)
> > > which will only be around for a few years.  Arguably SMP isn't even
> > > around now ... the AMD machine on which I'm typing this is firmly NUMA
> > > with a good 10% penalty for accessing memory owned by the other
> > > socket.
> >
> > 10% is nothing compared to the orders of magnitude cost of message
> > passing.
>
> Or you could use shared memory (as I said below).

As we recently quantified, that is also 100x slower without a concurrent GC.

> > > > A concurrent GC should be developed.  But I think you can compete in
> > > > some "niches" without a concurrent GC.
> > >
> > > Why should a concurrent GC be developed?  Threaded code is a nightmare
> > > to write & debug, and it's only convenient for lazy programmers who
> > > can't be bothered to think in advance about how they want to share
> > > data.  OCaml supports fork, event channels & shared memory right now
> > > (and has done for years) so there is no penalty to writing it
> > > properly.
> >
> > Ten years ago that was:
> >
> >   "Why should we use gargage collection? Garbage collectors are a
> > nightmare to implement and debug and are only useful for lazy programmers
> > who cannot be bothered to deallocate values themselves. C++ has reference
> > counting right now and there is no penalty for using it properly."
>
> Thanks for the straw man argument there.  Garbage collectors and _not_
> using threads both improve the safety of the language.

Avoiding threads does not improve the safety of the language, it simply 
degrades the capabilities of the language.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e