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 some
On Wednesday 08 June 2005 09:12, 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.
I had a chance to meet Bob Lentini (SAW's developer) about ten yea
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 arra
si Laako <[EMAIL PROTECTED]>
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
[Simon Jenkins]
...which your Descriptor template can pick up without using any
specialisation like this:
template
class Descriptor
: public DescriptorStub
{
public:
Descriptor() { UniqueID = T::UniqueID; }
...
};
Just a thought.
And a good one, thanks. Set me thinking and I think I
On Wednesday 08 Jun 2005 21:56, Jussi Laako wrote:
> On Wed, 2005-06-08 at 21:41 +0100, Chris Cannam wrote:
> > Are you sure this is still true in the gcc world, after they
> > changed vector from an array to a real class in gcc 3.3 or whenever
> > it was?
>
> Abovementioned template is not based o
On Wed, 2005-06-08 at 21:41 +0100, Chris Cannam wrote:
> 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
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 worl
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 companie
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 eve
On Wed, 08 Jun 2005 22:19 , Jussi Laako <[EMAIL PROTECTED]> sent:
>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 v
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 14:08 +0200, Alfons Adriaensen wrote:
> > typedef list 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
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 musi
>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
enoug
>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 talk
On Wed, 08 Jun 2005 09:50 , Simon Jenkins <[EMAIL PROTECTED]> sent:
>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 r
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 vector Foos;
>
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 :
>When all you need is the random access of a C array (or maybe even less,
>just sequential acces), and this is something you should know _before
>writing one letter of code_, why waste your time by writing it first using
>a vector and changing it afterwards ? Just write it using an array _from
>the
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 cou
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 w
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 usi
On 2005-06-05T05:14:50-0500, Jan Depner wrote:
> I've often wondered why anyone would use vectors.
Vectors can be resized dynamically (or sized up front), and their
interface is consistent with other STL constructs. Code is already
written and tested. You may not consider that important, and the
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:
> > > >
> > > > >
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'.
On Tue, 7 Jun 2005 10:18 , Paul Winkler <[EMAIL PROTECTED]> sent:
>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 progra
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 b
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 t
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 t
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
> dangero
On Mon, 2005-06-06 at 10:43 +0200, Tim Goetze wrote:
>
> What I have is this (from caps code):
>
> class DescriptorStub
> : public LADSPA_Descriptor
> {
>/* just a constructor and destructor here */
> };
>
> template
> class Descriptor
> : public DescriptorStub
> {
>public:
> Descr
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
> :-).
Act
[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 s
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
> > do
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
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 bein
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 -O2
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 a gcc extension so it is evil"
It's a gcc extension so^H^Hfor com
>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 yo
[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 co
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
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 __as
[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:
void f()
{
__asm__ ("nop\n"
"nop\n");
}
May compile fine, but like this a 100-line __asm__ goes well beyond my
pain t
Tim Goetze wrote:
> Enter gcc version 3, which drops multi-line inline assembly support.
The following compiles fine with gcc 3.3.3:
void f()
{
__asm__ ("nop\n"
"nop\n");
}
> Enter gcc version 3, moving the vtable member to memory offset 0 of a
> derived type even if the
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 both worlds - clean objects
> > and
> > low level.
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 r
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 a
[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
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
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, 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:
>
>
> http://shootout.alioth.d
[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.
Trus
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. Th
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 shootou
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
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.
Trusting that unspec
[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 it
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 th
[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
pr
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 re
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 mani
62 matches
Mail list logo
