From: Mathieu Bouchard (matju@artengine.ca)
Date: Fri Feb 04 2011 - 20:16:46 EST
On Tue, 1 Feb 2011, Scott Wilson wrote:
> The backend implementation of Arrays in SC is fairly optimised AFAIK,
> but of course it will never beat a C array. But objects have other
> advantages...
It's not a matter of objects vs non-objects.
> Well, let's see, numbers are objects, classes are objects, nil is an
> object, booleans are objects, err... there's nothing I'm aware of that
> you can assign to a variable that isn't an object.
The variable itself is not an object, for example.
> SC has 'typed' array subclasses like FloatArray, DoubleArray, etc., so
> you can use those if you don't need polymorphism.
Ah, that's good.
But a FloatArray that has the same methods as a DoubleArray is already a
form of polymorphism. (at a different level in the programme)
> But then I don't really want to get into a debate abut the virtues of
> static vs. dynamically typed languages.
I'm not necessarily about static typed languages. In any case I'm in
favour of mixed typing : various combinations of static and dynamic typing
to get the best of both worlds. To be able to access a DoubleArray and a
FloatArray in the same manner and to be able to choose it at runtime, that
is what I'm into.
>> Obviously you haven't been in the situation where 99 % of your processing
>> time is spent on multidimensional arrays. This happens to me most of the
>> time that I spend with PureData.
> Obviously?
Because then you wouldn't claim that the overhead is trivial.
> No, not directly. But yes, I'm sure if someone was doing that there
> would be custom objects for dealing with video frames, etc. To be
> honest, I didn't really mean to imply that nobody has done it (people
> have done surprisingly 'diverse' things), just that there doesn't seem
> to have been enough of a need for a squeeze the last drop of performance
> implementation in the language to add one to the main distribution.
Well, if the video is being done in the server and the stuff we're
discussing in the client, ... if you expect all the big number crunching
to happen in the server anyway, you don't need fast multidimensional
arrays in the client (nor any more specialised variants, such as video
buffers).
> But then I don't really want to get into a debate about the virtues of
> object oriented languages. ;-)
I'm not trying to discuss that. But I have the impression that you think
that I am talking about non-OOP, when in fact, I haven't really said
anything against OOP.
My point is more about the size of objects and the manner of breaking down
the problems. Cutting data into more objects doesn't make the programme
more object-oriented than not.
> But as you've mentioned the diversity of users' needs, it's perhaps
> worth keeping in mind that the sort of thing you're concerned with – as
> fast as possible lookup in an array where the dimensions are known and
> consistent – is only one use of multi-dimensional collections.
Well, I usually use runtime dimensions, rather than compiletime
dimensions. Are you assuming that I'm talking about compiletime
dimensions, or am I misunderstanding you ?
> There are many others which require different types of performance, and
> it's true that convenience, stability, ease of programming,
> adaptability, comprehensibility, etc., are also 'performance' issues.
Yes, I understand that. (Or else I'd code everything in C++Â ; but I
don't.)
> FWIW, as an example of some informal benchmarking, Dan Stowell did a
> comparison of SC and a number of other languages for a tree recursion
> task: http://www.mcld.co.uk/blog/blog.php?276
I'll tell you upfront that this is something that PureData really sucks
at.
I think you have reason to enjoy SC3 for that kind of thing, both for the
ability to programme that kind of thing easily, and for the speed of the
interpreter.
However, the benchmarks results are very weird. The blue horizontal line,
especially. I think that the benchmarker should take it as a hint that
either something is very wrong, or needs to be explained to the readers.
After that gets solved, it would be good to investigate why, despite SC3's
speed being so comparable to Octave's, but it's possible that a corrected
benchmark would show straighter lines.
> It falls behind once the numbers get higher, but that's not surprising
> given its domain.
I doubt that SC3 is really any slower than Octave (except by a small
percentage), but it would need a new benchmark. I'm telling you just
because of how the plot looks like.
_______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
This archive was generated by hypermail 2.1.5 : Sat Feb 05 2011 - 08:42:02 EST