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 BAA01801 for caml-redistribution; Sun, 10 Oct 1999 01:53:06 +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 VAA16236 for ; Fri, 8 Oct 1999 21:22:10 +0200 (MET DST) Received: from ruby (pm1-25.triode.net.au [203.63.235.41]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id VAA16671 for ; Fri, 8 Oct 1999 21:22:06 +0200 (MET DST) Received: from maxtal.com.au (IDENT:root@localhost [127.0.0.1]) by ruby (8.9.3/8.9.3) with ESMTP id FAA07344; Sat, 9 Oct 1999 05:15:45 +1000 Sender: weis Message-ID: <37FE42E1.3D0B9ADE@maxtal.com.au> Date: Sat, 09 Oct 1999 05:15:45 +1000 From: skaller Organization: Maxtal P/L X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.12 i586) X-Accept-Language: en MIME-Version: 1.0 To: Gerd.Stolpmann@darmstadt.netsurf.de CC: caml-list@inria.fr Subject: Re: speed versus C References: <37FC4419.6C9E3B02@maxtal.com.au> <99100800493701.23684@ice> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gerd Stolpmann wrote: > > >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? Sure: too many, and not enough ocaml experience. But a good place to start would be to examine the C++ Standard Template Library. There are various 'classical' data structures which should be available: singly linked lists, doubly linked lists, arrays of fixed length, arrays of variable length, binary trees with various balancing acts, quad trees, b-trees, hash tables, graphs, directed graphs, DAGS, stacks, queues, priority queues, .. There are also some more exotic ones: a generic garbage collector for arbitrary resources, for example, would be interesting to consider. There are also a lot of numerical algorithms known :-) > It's only from experience, and I have often good > results with lists or trees. Yes, but they do not perform at all well when random access is required. > 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. I am not saying anything 'bad' against it, just that in such cases, it is unlikely performance matters either: we should be considering library code and intensive applications using it, when comparing say, C/C++ and ocaml, since that is where the benefits of one or the other really start to count. > > 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. I believe I would not design a program requiring it, but my task is to implement an existing specification that does require it. So I must find a solution, abandon the project, modify the specifications, or try another language. -- John Skaller, mailto:skaller@maxtal.com.au 1/10 Toxteth Rd Glebe NSW 2037 Australia homepage: http://www.maxtal.com.au/~skaller downloads: http://www.triode.net.au/~skaller