From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id D17C9BBAF for ; Wed, 24 Nov 2010 17:26:49 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4EAN7L7EzAbSoIYGdsb2JhbACDTpErjgYLHyUEHq4MkQSBIYMzcwSQXw X-IronPort-AV: E=Sophos;i="4.59,249,1288566000"; d="scan'208";a="80137255" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Nov 2010 17:26:49 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from localhost (okapi.in-berlin.de [192.109.42.117]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id oAOGQmih018839 for ; Wed, 24 Nov 2010 17:26:48 +0100 Received: from e178040185.adsl.alicedsl.de (e178040185.adsl.alicedsl.de [85.178.40.185]) by webmail.in-berlin.de (Horde Framework) with HTTP; Wed, 24 Nov 2010 17:26:48 +0100 Message-ID: <20101124172648.635060xea9et75jc@webmail.in-berlin.de> Date: Wed, 24 Nov 2010 17:26:48 +0100 From: "Oliver Bandel" To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Is OCaml fast? References: <86AD9C8D-EB50-40E9-83D2-E5B5B4D3382F@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) 4.3.3 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Spam: no; 0.00; bandel:01 in-berlin:01 ocaml:01 ocaml:01 ocamlopt:01 arrays:01 langauge:01 pointers:01 compilation:01 beter:98 usd:98 oliver:01 oliver:01 compile:01 caml-list:01 Hi, Zitat von "Thanassis Tsiodras" : [...] > Over the last couple of days, I've played a lot with ocaml (to be > exact, Linux/ocamlopt, since my interest in the speed of what I make > remains dominant) [...] OK, then I asume, you will be one of the programmers who pick out the right datastructures for his applications. When looking at C because of speed, this is completely ok. But I would estimate that 80% or 90% of the programmers just don#t think enough on that topic. Many people who work as programmers, just pick a language and a library.... just that library that is the most mainstream library and start working. Also many C-programmers I have seen have just done seemingly simple hacking and not thought about data structures enough. For simple programs and little amount of input data that's often ok, but in the history of a program will turn out as bad decision. So: what are all these benchmarks on different data structures worth, if C-programmers always stick to arrays, or, maybe, to linked lists? When I see how Gnome (and I would guess other desktop environments =20 will handle it thje same) handles areas of the screen.... that it does =20 not use trees that are appropriate for handling two-dimensional =20 spatial data, and then experience slow behaviour, then all is said.... I mean: OK, a low performant language will definitley make things =20 slower than a higher performant one - when usd with the same algorithms. But when one does not use intelligent programming, this all does not =20 help much. Then you can use C and be slower than, say, Python (which btw also =20 offers some nice datastructures, like Sets and so on). But maybe what I write here is nothing new to you. I just wanted to have it mentioned, that benchmarks alone does not =20 guarantee fast running programs. A langauge that supports you to easily implement the datastructures you would like to use, is much better supporting you then in this respect, because if it needs toomuch effort to implement such a datastructure, =20 lazyness of the programmer might be stronger than the will to use =20 beter data structures.... especially if you have to fight with =20 dangling pointers on the one hand, where you on the other hand will be =20 warned in advance, that you just didn't got the types right and the =20 program will not compile then... which yields in fixing errors at =20 compilation stage. Ciao, Oliver