From: Gerd Stolpmann <Gerd.Stolpmann@darmstadt.netsurf.de>
To: skaller <skaller@maxtal.com.au>
Subject: Re: speed versus C
Date: Fri, 8 Oct 1999 00:18:32 +0200
Message-Id: <99100800493701.23684@ice>
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 ----------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:26 MET