From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA29319 for caml-redistribution; Fri, 8 Oct 1999 11:58:45 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA29918 for ; Fri, 8 Oct 1999 00:49:42 +0200 (MET DST) Received: from beach.frankfurt.netsurf.de (beach.frankfurt.netsurf.de [194.64.181.2]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id AAA18697 for ; Fri, 8 Oct 1999 00:49:41 +0200 (MET DST) Received: from ice.darmstadt.netsurf.de (board-103.darmstadt.netsurf.de [194.163.86.231]) by beach.frankfurt.netsurf.de (8.8.5/8.8.5) with ESMTP id AAA06421; Fri, 8 Oct 1999 00:49:39 +0200 (MET DST) Received: from localhost (localhost [[UNIX: localhost]]) by ice.darmstadt.netsurf.de (8.9.3/8.9.3) id AAA24974; Fri, 8 Oct 1999 00:49:37 +0200 From: Gerd Stolpmann Reply-To: Gerd.Stolpmann@darmstadt.netsurf.de Organization: privat To: skaller Subject: Re: speed versus C Date: Fri, 8 Oct 1999 00:18:32 +0200 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain References: <37FC4419.6C9E3B02@maxtal.com.au> Cc: caml-list@inria.fr MIME-Version: 1.0 Message-Id: <99100800493701.23684@ice> Content-Transfer-Encoding: 8bit Sender: weis On Thu, 07 Oct 1999, John Skaller wrote: > The factor is likely much worse than two. Doing multiple precision >arithmetic, the factor is two, but even specially optimised simulations >of 32 bit ints by 16 bit ones often involve a more than two >instructions, >and this impacts cache performance severely in tight loops. It is very hard to estimate this. I know that there are more instructions necessary but I do not know how much they weight compared with the whole task. Cache performance decreases obviously because the double amount of data must be processed (cryptographic algorithms perform lookups in precalculated tables). The cache efficiency is hard to predict, I had strange effects while manually optimizing the code. >> As already pointed out, Ocaml is not designed for such problems, and this >> slow-down factor is an upper limit. > > That depends on what kinds of data structures you are working with. >Ocaml has some problems requiring many things to be initialised >unnecessarily. >Also, where the library lacks certain facilities, it is occasionally >harder to provide efficient data structures than in C. These problems >are not intrinsic to ocaml, but can be solved by carefully considered >extension >of the standard library. Any ideas? >>The typical application will have a speed >> which is comparable with C/C++ solutions, as there are a number of advantages: >> >> - The recursive data types of Ocaml are often more problem-oriented than >> "imperative" data structures. > > I don't think it is entirely reasonably to claim this; I find that >the 'imperative' data structures are more generally applicable. >Singly linked immutable lists are a special case well supported by ocaml >(and most other functional languages) but their performance is abysmal >for applications for which they are not suited. No, not entirely reasonable. It's only from experience, and I have often good results with lists or trees. "Problem-oriented" simply means that lists and trees are very frequent in real world problems; I do not want to claim that they work well for any problem, this is definitely not true. >> - Memory management is much better; but this counts only for long-running >> applications. Many C/C++ programs only "malloc" and do not "free", so the >> time consumption of these functions isn't a problem. > > I do not think 'micky mouse' programs that fail to release >memory are worth considering here. C++ memory management can be >very difficult to get both correct and efficient, and sometimes >implementation details invade the program structure. The world is full of such 'micky mouse' programs, and they are really used. Not freeing memory is very common if the amount of allocated data is not very high at all, or if the program runs only for a short time. There is nothing bad to say against it. > However, C++ allows finalisation and ocaml doesn't, >which is a serious problem in ocaml when it is needed. Up to now I did not need finalisation, so I have no experience. Gerd -- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 100 64293 Darmstadt EMail: Gerd.Stolpmann@darmstadt.netsurf.de (privat) Germany ----------------------------------------------------------------------------