Version française
Home     About     Download     Resources     Contact us    
Browse thread
speed versus C
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@m...>
Subject: Re: speed versus C
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