Chris Cannam a écrit :
Yes, indeed, but a couple of times here I've seen observations that a
vector would compile to an array if optimisation was on, etc. Since
we're mostly using gcc-3.3+ now, I wanted to ask if anyone is sure
whether that's really true.
Since a vector is a wrapped C
On Thu, 2005-06-09 at 09:47 -0400, Fred Gleason wrote:
[regarding writing full apps in asm]
Today however, I think it'd be a foolish choice. Modern systems have orders
of magnitude more processing power, and it'd be silly to devote 10x the time
developing an assembly-based version of
On Tue, 2005-06-07 at 19:34 -0500, Jan Depner wrote:
On Tue, 2005-06-07 at 19:20, Dave Robillard wrote:
Premature optimization is the root of all evil. Using C arrays and
strings for no reason when a much more robust higher level type would
suffice is /just as stupid/ as always using slow
On Wed, Jun 08, 2005 at 10:20:01AM +1000, Dave Robillard wrote:
Premature optimization is the root of all evil.
That's by Donald Knuth IIRC. Most of wht I know about programming
(I mean relevant things, not language or system nitty-gritty), comes
from hist ACP series of books, and I'd agree
On Wed, Jun 08, 2005 at 09:50:42AM +0100, Simon Jenkins wrote:
Suppose I sum a vector of 5 million integers and it takes 6 seconds. And
assume - (generously![1]) - that I switch to using an array and now it
only takes 1 second. Hmmm... a 6 * speedup! So I look to see where else
my code could
Paul Davis [EMAIL PROTECTED] wrote:
i'll leave making things as fast as possible to intel, AMD and the gcc team.
When I read this when you posted this the first time, I thought: and
what about PPC? But now, after Steve Jobs WWDC keynote, it turns out
that your omission of PPC was visionary :-)
On Wed, Jun 08, 2005 at 07:19:56AM -0400, Paul Davis wrote:
the nice thing about a
design pattern like STL containers is that you can toggle back and
forth between any all of them with almost no work. i can't count how
many times in ardour i have changed:
typedef vectorFoo Foos;
to
Again, valid point. But algorithmic design IMHO includes the selection
of the right data structures and interfaces in function of the required
data / time complexity.
absolutely.
As to assembler, I've no problem with it per se - you can write well
[ ... ]
In both cases, we're probably talking
As far as data volumes go, for your 5 million integers, you're off by about
5
orders of magnitude ;-) So, now that 5ms just became 500 seconds. Yes, my
users do notice and appreciate that time savings ;-)
Jan
Sooo. if you stored this stuff on punched paper tape it would be long
enough to
On Wed, Jun 08, 2005 at 09:12:05AM -0400, Paul Davis wrote:
SAWstudio is a pretty full-featured DAW that is, AFAIK, written almost
entirely in x86 assembler. Its blazingly fast and yet dinosaur like at
the same time, from what I hear.
Reminds me of the original version of Sibelius (the music
On Wed, 2005-06-08 at 14:08 +0200, Alfons Adriaensen wrote:
typedef listFoo Foos;
Valid point, there are occasions where you can do this sort of thing.
But when we are talking about large data sets and heavy use, it could
lead to some nasty surprises. For small data sets, it doesn't
On Wed, 2005-06-08 at 05:47 -0700, [EMAIL PROTECTED] wrote:
I'm working with multibeam sonar, airborne topographic and hydrographic
LIDAR, and airborne hyperspectral imagery data.
Sonar and radar applications are very familiar to me. There is no reason
why those couldn't be very efficient,
On Wed, 2005-06-08 at 22:09 +0300, Jussi Laako wrote:
And you can still access the individual samples by using vData[n]
without significant performance penalty compared to a simple float
array. And I say significant here just because it also performs bounds
checking. It could be made even
On Wednesday 08 Jun 2005 21:45, [EMAIL PROTECTED] wrote:
then processing speed becomes extremely important. There have been
some very good points made in this discussion and I will definitely
investigate some of them. My problem here is that I've heard the
same type of thing from companies
On Wednesday 08 Jun 2005 21:35, Jussi Laako wrote:
You can derive a new class from the template and overload the []
operator to perform exactly same as in C. After compilation the
result is the same no matter if the template or C array is used.
Are you sure this is still true in the gcc world,
[Simon Jenkins]
...which your Descriptor template can pick up without using any
specialisation like this:
template class T
class Descriptor
: public DescriptorStub
{
public:
Descriptor() { UniqueID = T::UniqueID; }
...
};
Just a thought.
And a good one, thanks. Set me thinking and I
]
Subject: Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too
many
On Wednesday 08 Jun 2005 21:35, Jussi Laako wrote:
You can derive a new class from the template and overload the []
operator to perform exactly same as in C. After compilation the
result is the same no matter
On Mon, Jun 06, 2005 at 04:12:27PM -0500, Jan Depner wrote:
I just have to respond to this. I have been writing code for 27
years and every time I get a neophyte programmer in they want to cut
corners to save programming time. Here's the bottom line - if it saves
you a day in coding but
On Mon, 2005-06-06 at 15:45 -0500, Jan Depner wrote:
On Sun, 2005-06-05 at 23:53, Dave Robillard wrote:
On Sun, 2005-05-06 at 05:14 -0500, Jan Depner wrote:
On Sun, 2005-06-05 at 08:08, fons adriaensen wrote:
My aproach to C++ is very simple: I use it as 'C with classes'. No
On Tue, 2005-06-07 at 19:20, Dave Robillard wrote:
On Mon, 2005-06-06 at 15:45 -0500, Jan Depner wrote:
On Sun, 2005-06-05 at 23:53, Dave Robillard wrote:
On Sun, 2005-05-06 at 05:14 -0500, Jan Depner wrote:
On Sun, 2005-06-05 at 08:08, fons adriaensen wrote:
My aproach to C++
Tim Goetze wrote:
[Clemens Ladisch]
Tim Goetze wrote:
Enter gcc version 3, which drops multi-line inline assembly support.
The following compiles fine with gcc 3.3.3:
__asm__ (nop\n
nop\n);
May compile fine, but like this a 100-line __asm__ goes well beyond
On Monday 06 June 2005 00:53, Dave Robillard wrote:
Good answer. I've often wondered why anyone would use vectors.
Because they dynamically resize, easily, and are generally much simpler
to work with, perhaps? :)
Not to mention being more-or-less fully debugged and stable.
I think it's
[Clemens Ladisch]
You mean you want to omit \n and the quotes? That was always invalid
in both C and C++.
Makes me wonder how come it used to compile cleanly then. Now please
don't tell me it's a gcc extension so it is evil because __asm__ is
already kissing portability goodbye.
You
Of course, there are also situations where it's absolutely right and necessary
to optimize for every ounce of speed possible. The point is that it really
depends upon the specific situation and design -- to say that 'so-and-so
technique is *always* better' is naive. This is why profiling your
David Cournapeau a écrit :
I always though myself that vector are slower than C array if use
right, some other people more knowledgable than me tell me the
contrary, but I havn't see any code or real case that prove it.
std::vector should compile to a C array when compiling with -O3 (or
Fred Gleason [EMAIL PROTECTED] writes:
On Monday 06 June 2005 00:53, Dave Robillard wrote:
Good answer. I've often wondered why anyone would use vectors.
Because they dynamically resize, easily, and are generally much simpler
to work with, perhaps? :)
Not to mention being
On Sat, Jun 04, 2005 at 04:59:06PM +0200, Tim Goetze wrote:
Scene II:
Our hero puts years of work into an all-round realtime audio and MIDI
library that expands the Python programming language.
(snip)
said library dies a slow and painful but equally unsung death.
I was wondering what the
Es geschah am Montag 06 Juni 2005 15:17 als Clemens Ladisch schrieb:
Tim Goetze wrote:
[Clemens Ladisch]
You mean you want to omit \n and the quotes? That was always invalid
in both C and C++.
Makes me wonder how come it used to compile cleanly then. Now please
don't tell me it's
[Paul Winkler]
I was wondering what the reason was for dropping midithing.
I played with it briefly and quite liked it. Sad indeed.
My ambitions at that time were surpassing the concept; I was also not
satisfied with the general code quality.
Leading me to wonder, how long before Milk is
On Monday 06 June 2005 10:37, Mario Lang wrote:
Heh, thats a Redmond argument I'd say :-).
There is nothing wrong (ok, not that much) with accidentally
wasting CPU time, but if you are aware of where are you
wasting it, I dont buy the argument that it is OK to leave it like that
:-).
On Sun, 2005-06-05 at 20:15, David Cournapeau wrote:
Good answer. I've often wondered why anyone would use vectors.
Because you don't need to worry about their deletion ? Granted that for
pure audio processing programming, it is not really useful, and a bit
dangerous.
I
On Sun, 2005-06-05 at 23:53, Dave Robillard wrote:
On Sun, 2005-05-06 at 05:14 -0500, Jan Depner wrote:
On Sun, 2005-06-05 at 08:08, fons adriaensen wrote:
My aproach to C++ is very simple: I use it as 'C with classes'. No
streams, no
STL, no other nonsense. Gives me the best of
On Mon, 2005-06-06 at 10:38, Fred Gleason wrote:
On Monday 06 June 2005 10:37, Mario Lang wrote:
Heh, thats a Redmond argument I'd say :-).
There is nothing wrong (ok, not that much) with accidentally
wasting CPU time, but if you are aware of where are you
wasting it, I dont buy the
On Sat, 2005-06-04 at 16:59 +0200, Tim Goetze wrote:
Enter gcc version 3, which drops multi-line inline assembly support.
Enter gcc version 4, which requires the templated types' constructor
code be rewritten in the most nonsensical, misleading and ugly fashion
I've been maintaining my
Es geschah am Sonntag 05 Juni 2005 04:18 als Erik de Castro Lopo schrieb:
I also find Ocaml a better high level language than Python because
it is strictly and statically typed as well as compiling to native
binaries which come close to the speed of C. The (very flawed IMO)
language shootout
Christian Schoenebeck wrote:
Es geschah am Sonntag 05 Juni 2005 04:18 als Erik de Castro Lopo schrieb:
I also find Ocaml a better high level language than Python because
it is strictly and statically typed as well as compiling to native
binaries which come close to the speed of C. The
[Erik de Castro Lopo]
Tim Goetze wrote:
To be honest, I don't know if it's undefined behaviour; I don't read
ISO compiler ABI standards (if they exist in the first place). I was
simply trusting that common sense would always allow this
cross-language subclassing, apparently I was wrong.
On Sun, Jun 05, 2005 at 10:12:06PM +1000, Erik de Castro Lopo wrote:
It should be noted that the benchmark attempts to use the technique
most approriate for the language. So, for the count words example,
the C++ version uses std::vector from of the STL:
On Sun, 2005-06-05 at 15:08 +0200, fons adriaensen wrote:
My aproach to C++ is very simple: I use it as 'C with classes'. No streams, no
STL, no other nonsense. Gives me the best of both worlds - clean objects and
low level.
Same here, except;
- exceptions make error handling simpler and
On Sun, 2005-06-05 at 08:08, fons adriaensen wrote:
My aproach to C++ is very simple: I use it as 'C with classes'. No streams, no
STL, no other nonsense. Gives me the best of both worlds - clean objects and
low level.
Good answer. I've often wondered why anyone would use vectors. I
[Jussi Laako]
On Sun, 2005-06-05 at 15:08 +0200, fons adriaensen wrote:
My aproach to C++ is very simple: I use it as 'C with classes'. No streams, no
STL, no other nonsense. Gives me the best of both worlds - clean objects and
low level.
Same here, except;
- exceptions make error handling
Es geschah am Sonntag 05 Juni 2005 14:12 als Erik de Castro Lopo schrieb:
Christian Schoenebeck wrote:
Es geschah am Sonntag 05 Juni 2005 04:18 als Erik de Castro Lopo schrieb:
I also find Ocaml a better high level language than Python because
it is strictly and statically typed as well
Good answer. I've often wondered why anyone would use vectors.
Because you don't need to worry about their deletion ? Granted that for
pure audio processing programming, it is not really useful, and a bit
dangerous.
I always though myself that vector are slower than C array if use
Frailty, thy name is GCC
A Modern Drama in Three Scenes.
Dramatis Personae: An ardent programmer and a popular C++ compiler
-*-
Prologue:
Appalled by the rat race commonly known as the proprietary software
business, our young and gifted hero joins the light side, deeply
inspired by the
Tim Goetze [EMAIL PROTECTED] writes:
Epilogue:
Our hero has completely and permanently lost his faith in the popular
compiler. Disillusioned and indecisive, he resigns himself to
henceforth reluctantly write C++ only to support his miserable
life. His plight is so bad he downright refuses
[Jack O'Quin]
Anticlimax: ;-)
Our hero sees the error of his ways. Eschewing the grotesque
compromises imposed on C++ by its quixotic quest (??) for Object
Oriented Programming Without Garbage Collection (OOPWGC), he returns
to sanity, living happily ever after, writing robust, portable
Tim Goetze wrote:
Frailty, thy name is GCC
A Modern Drama in Three Scenes.
Dramatis Personae: An ardent programmer and a popular C++ compiler
-*-
Prologue:
Appalled by the rat race commonly known as the proprietary software
business, our young and gifted hero joins the light
[Erik de Castro Lopo]
Tim Goetze wrote:
Enter gcc version 3, moving the vtable member to memory offset 0 of a
derived type even if the base type is in C which doesn't know about
vtables.
Relying on undefined behaviour will, sooner or later, result in tears.
To be honest, I don't know if
48 matches
Mail list logo
