4 Jun
2005
4 Jun
'05
1:03 p.m.
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 manifold yet subtle qualities of free software.
Scene I:
Our hero in day-and-night-long sessions optimizes the hell out of a
SSE2-based n*4-band IIR equalizer. Of course in assembly, and mixed
with C++ templating. The final code is about 10% faster than floats on
AMD, probably a fair bit quicker yet on P4 systems.
Enter gcc version 3, which drops multi-line inline assembly support.
Said assembly code becomes effectively unusable and dies a quick and
unsung death.
Scene II:
Our hero puts years of work into an all-round realtime audio and MIDI
library that expands the Python programming language. While having its
flaws, it's a versatile, surprisingly stable and immensely capable
system, partly thanks to a very clever (according to our hero) design
that subclasses Python's C types in C++.
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. As a result, the very foundation of said library's type
system is rendered nonfunctional since Python expects its type header
to reside in the very same memory location. With no precautions for
such an abrupt change taken and the implications requiring a manual
review and substantial rewrite of a good 50.000 lines of source code,
said library dies a slow and painful but equally unsung death.
Scene III:
Our hero bundles his DSP efforts into a free plugin library, once
again saving himself much work and improving code readability by using
C++ templates, resulting in quite an elegant object system and source
code, hethinks.
Enter gcc version 4, which requires the templated types' constructor
code be rewritten in the most nonsensical, misleading and ugly fashion
possibly imaginable this side of Hungary and Redmond, WA, according to
our (now not so very young anymore) hero.
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 to support the latest
follies of the popular compiler in his free software efforts.
-*-
Will this be the end? To be continued, hopefully.
Cheers, Tim
4 Jun
4 Jun
1:57 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Tim Goetze <tim(a)quitte.de> 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 to support the latest
follies of the popular compiler in his free software efforts.
-*-
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
programs in C, "the world's most widely used assembly language", where
what you see is what you get, regardless of the underlying platform
and compiler.
Will this be the end? To be continued, hopefully.
Indeed. I feel your pain. (And, you haven't really explored the full
range of ABI incompatibility problems.)
--
joq
9:43 p.m.
New subject: [linux-audio-dev] M-Audio and jack
Hi all,
I have a Compaq Presario notebook with an AMD64 3000+ and I am trying to use
an M-Audio MobilePre for home studio and realtime effects.
This machine comes with an nforce3 chipset, including an intel8x0 sound
card.
I have a 2.6.12rc4-mm2 kernel with the realtime module loaded.
I also have tmpfs mounted on /tmp
I have two problems with jack:
With the intel8x0 I can get jackd to run smoothly, but sometimes (when
launching some program for example) I get many xruns even with realtime
scheduling. Here's how I start it:
jackd -R -d alsa -d "hw:0" -p128 -n2 -S -r48000
but still, it works quite decently. I tried this with realtime effects
(ecamegapedal)
and no problem.
However, if I try the same configuration with the the M-Audio card
(which is mapped to card 2, full duplex is implicit)
jackd -R -d alsa -d "hw:2" -p128 -n2 -S -r48000
I get a lot of xruns. Then, if I try something like
jackd -R -d alsa -d "hw:2" -p512 -n2 -S -r48000
I get NO xruns either, but the sound is completely "chopped". This only
stops happening with a period size of 2048!! Of course, at this point I can
only use it as a recording/playback device but I have to forget about
realtime
effects!
I know that the USB 2.0 bandwidth is more than enough to work in full
duplex mode with two channels at 48000hz (even USB 1.1 bandwidth is
enough for this purposes). Can it be something about the snd-usb-audio
driver being too slow?
Any suggestions?
Thanks,
Ignacio Ramirez.-
10:16 p.m.
New subject: [linux-audio-dev] M-Audio and jack
On Sat, Jun 04, 2005 at 08:43:45PM -0300, Ignacio Ram?rez wrote:
However, if I try the same configuration with the the
M-Audio card
(which is mapped to card 2, full duplex is implicit)
jackd -R -d alsa -d "hw:2" -p128 -n2 -S -r48000
I get a lot of xruns. Then, if I try something like
jackd -R -d alsa -d "hw:2" -p512 -n2 -S -r48000
I get NO xruns either, but the sound is completely "chopped". This only
stops happening with a period size of 2048!! Of course, at this point I can
only use it as a recording/playback device but I have to forget about
realtime
effects!
Try -p128 -n3, or -p256 -n3
Having a total buffer size that is a multiple of 48 often helps with USB.
--
FA
10:15 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
[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
programs in C, "the world's most widely used assembly language", where
what you see is what you get, regardless of the underlying platform
and compiler.
The trouble with our surely no less quixotic hero (coming up with this
drama has made me know him so well I could sometimes swear he's alive)
is that he's lazy, and he's gotten addicted to the seductions of
cleverness, always looking for ways to evade the load of work that a
more modest way imposes on the aspiring.
So, he's a bit reluctant to go back to the verbose and honest ways of
plain C. He might even have trouble fluently reading and writing
25-character identifiers, so shortened is his patience and so
re-evolved his typing.
I'm not a big fan of turning this case into a tragedy, so I'm quite
hopeful there'll be Part II to be played to the same public, in which
this conflict will be ultimately resolved.
Indeed. I feel your pain. (And, you haven't
really explored the full
range of ABI incompatibility problems.)
Nor would I care to :) though what I've experienced is enough to
affect the full range of what I used to think of as a main work, the
effects being pretty much the equivalent of a nuclear blast to be
precise. I've looked up a bit of the public documentation of the
vtable movement decision process when gcc 3 was in the works, and the
only clearly stated reason seems the Solaris compiler having the habit
of placing the vtable at this + 0. Maybe I should have delved deeper
in the hope of finding a better reason but reading that somehow made
me turn my interest elsewhere; the prospect of fighting this decision
seemed unattractive anyway (gcc 3.3 was already shipped so late was I
to notice).
However, I'm constantly rethinking the way I make music and how I use
the computer to aid me, so the next attempt, if there'll be one, can
reflect newly found concepts.
Thanks for the good words,
Tim
10:11 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 side, deeply
inspired by the manifold yet subtle qualities of free software.
Scene I:
Our hero in day-and-night-long sessions optimizes the hell out of a
SSE2-based n*4-band IIR equalizer. Of course in assembly, and mixed
with C++ templating. The final code is about 10% faster than floats on
AMD, probably a fair bit quicker yet on P4 systems.
Enter gcc version 3, which drops multi-line inline assembly support.
Said assembly code becomes effectively unusable and dies a quick and
unsung death.
Scene II:
Our hero puts years of work into an all-round realtime audio and MIDI
library that expands the Python programming language. While having its
flaws, it's a versatile, surprisingly stable and immensely capable
system, partly thanks to a very clever (according to our hero) design
that subclasses Python's C types in C++.
Sound to me like that was relying on "undefined behaviour".
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.
Scene III:
Our hero bundles his DSP efforts into a free plugin library, once
again saving himself much work and improving code readability by using
C++ templates, resulting in quite an elegant object system and source
code, hethinks.
Enter gcc version 4, which requires the templated types' constructor
code be rewritten in the most nonsensical, misleading and ugly fashion
possibly imaginable this side of Hungary and Redmond, WA, according to
our (now not so very young anymore) hero.
Hmm, C++ bites again. I know little about C++, but maybe this last
change was due to some requirement of some C++ standard.
Our hero has completely and permanently lost his faith
in the popular
compiler.
Two out of the 3 above were C++ related and did not affect
the GNU C compiler.
Disillusioned and indecisive, he resigns himself to
henceforth reluctantly write C++ only to support his miserable life.
Can I sell you an Ocaml:
http://www.ocaml.org/
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"... a discussion of C++'s strengths and flaws always sounds
like an argument about whether one should face north or east
when one is sacrificing one's goat to the rain god."
-- Thant Tessman
11:02 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
[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.
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. Can I sell you an Ocaml:
http://www.ocaml.org/
Does it give me inline assembly, realtime-safeness and the performance
of C/C++? I'm quite fond of C in both incarnations, and paired with
Python it's quite a dream team that is hard to surpass, or
alternatively fit into.
Browsing the site, the tutorial shows code lines ending with two
semicola and assignments using a 'let' operator; first bitter pills
to swallow for a friend of code brevity to be sure.
It does look like it has its sweet spots after some more tutorial
browsing, however I'm afraid my ideal it is not.
Cheers, Tim
5 Jun
5 Jun
12:18 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Tim Goetze wrote:
Well I really like to separate the C and C++. C is unashamedly a
low level language. C++ OTOH tries to be both low level and high
level. In comparison to C, C++ is a poor low level language.
Compared to Python or Ocaml, C++ is a poor high level language.
So to answer your question, Ocaml will not give you the low level
stuff that is available in C (inline asm etc), but it is a much
better high level language than C++.
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 puts Ocaml compiled to native binaries as faster
than C++ but slower than C.
Linking low level C code to Ocmal is about the same complexity as
doing the same for Python.
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 unspecified/undocumented characteristics will remain
the same across versions is asking for trouble.
Can I sell you an Ocaml:
http://www.ocaml.org/
Does it give me inline assembly, realtime-safeness and the performance
of C/C++? Browsing the site, the tutorial shows code lines
ending with two
semicola and assignments using a 'let' operator; first bitter pills
to swallow for a friend of code brevity to be sure.
The syntax does have a few warts, but IMO no more than C++.
However, you should look at the big picture instead of the minor
details. Ocaml's bevity comes from it being a true high level
language like Python, not some psuedo high level constructs grafted
onto a low level language like C++.
I've done quite a bit of Ocaml over the last 9 months or so and
I find that for the tasks I was working on I can get a job done
in less lines of Ocaml code than it would take to get the same
task done in Python. That is brevity.
In adition, unlike Python my chances of getting run time errors
are reduced to almost zero because of Ocaml's strict, static
type checking. Errors that are runtime errors in Python are almost
always compile time errors in Ocaml.
It does look like it has its sweet spots after some
more tutorial
browsing, however I'm afraid my ideal it is not.
I have done some seriously difficult code in Ocaml; tasks that in
C or C++ would a nightmare of complexity and/or endless futzing
about with trivial minor details. It is not the ideal programming
language, but for some kinds of tasks it beats every other
programming language I've ever seen.
You might also find that Ocaml combined with C is a better option
than C++.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"The growing and dangerous intrusion of this new technology,
threatens an entire industry's economic vitality and future
security." -- Jack Valenti (MPAA president) on the video
cassette recorder, 1982.
9:42 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Es geschah am Sonntag 05 Juni 2005 04:18 als Erik de Castro Lopo schrieb:
Which isn't hard, is it?
CU
Christian
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 puts Ocaml compiled to native binaries as faster
than C++ but slower than C.
Hooo, that is a very brave claim, because it implies C++ binaries to be slower
than _equivalent_ C binaries. I wonder if you can proof it or if you really
compared it with todays C++ compilers.
Browsing the
site, the tutorial shows code lines ending with two
semicola and assignments using a 'let' operator; first bitter pills
to swallow for a friend of code brevity to be sure.
The syntax does have a few warts, but IMO no more than C++.
10:12 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Christian Schoenebeck wrote:
Es geschah am Sonntag 05 Juni 2005 04:18 als Erik de
Castro Lopo schrieb:
Not my claim. The claim is here:
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&s…
I believe that this shootout is somewhat flawed in that the examples
are all relatively short pieces of code unlike anything that even
approaches real world code.
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.debian.org/benchmark.php?test=wc&lang=icpp&i…
while the C version uses standard C arrays:
http://shootout.alioth.debian.org/benchmark.php?test=wc&lang=icc&id…
Are you surprised that C arrays are faster than std::vector?
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
" Baldie is such a wonderful villain
The Linux/OSS community could not possibly ask for a better villain than
our man Baldie. He is absolutely perfect for the part. Just look at his
creds: 1) Physically repulsive; 2) Morally bankrupt; 3) Megalomaniacal;
4) Possessed of a truly nasty, abusive disposition; 5) Prone to Hitlerian
ranting; 6) Stalinesque paranoia... The list just goes on and on. The man
has the gift of true despicability, no doubt about it. If it weren't for
Baldie we'd be stuck with Bilgatus' merely vacuuous and creepy persona
for an anthropomorphization of the Evil Empire -- tepid at best."
-- Matthew Alton in LinuxToday.com on Steve Balmer
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 puts Ocaml compiled to native binaries as faster
than C++ but slower than C.
Hooo, that is a very brave claim,
11:41 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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.debian.org/benchmark.php?test=wc&lang=icpp&i…
while the C version uses standard C arrays:
http://shootout.alioth.debian.org/benchmark.php?test=wc&lang=icc&id…
Are you surprised that C arrays are faster than std::vector?
I'm not, but there's no good reason for not using C arrays in C++. STL is just
a library, it's not part of the language, and you're free to use it or not.
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.
--
FA
12:41 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 more robust
- templates are good for abstraction in some cases
Problem with most STL implementations is that it's creating too complex
constructs using pure templates. Because of how templates are
implemented, I think template implementations should always be as simple
as possible with most of the actual code in 'real' classes.
I'm usually limiting inheritance in my implementations to maximum of two
or three levels and absolutely no multiple inheritance.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
1:12 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
[Jussi Laako]
On Sun, 2005-06-05 at 15:08 +0200, fons adriaensen
wrote:
I second both of you.
Cheers, Tim
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 more robust
- templates are good for abstraction in some cases
Problem with most STL implementations is that it's creating too complex
constructs using pure templates. Because of how templates are
implemented, I think template implementations should always be as simple
as possible with most of the actual code in 'real' classes.
I'm usually limiting inheritance in my implementations to maximum of two
or three levels and absolutely no multiple inheritance. 
1:04 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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
always use C arrays in C++. Vectors are slower than molasses in January
(or June for those in the southern half ;-)
Jan
3:32 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 great
part is we each get to make that choice.
I have not measured the difference between vectors and arrays, but would
defer such optimizations till it clear that it is an issue.
/Allan
11:12 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 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.
David
6 Jun
6 Jun
11:22 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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
-finline-functions). There should be no difference in speed.
11:30 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Sun, 2005-06-05 at 20:15, David Cournapeau wrote:
They are definitely slower. I'm just very careful with allocated
arrays.
Jan
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 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.
2:58 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Sun, 2005-05-06 at 05:14 -0500, Jan Depner wrote:
On Sun, 2005-06-05 at 08:08, fons adriaensen wrote:
Because they dynamically resize, easily, and are generally much simpler
to work with, perhaps? :)
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 always use C arrays in C++. Vectors are slower than
molasses in January
(or June for those in the southern half ;-)
FWIW, accessing elements in a vector with [] shouldn't be any slower
than doing the same on a C array.
Not that C++ doesn't still suck..
-DR-
10:16 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Monday 06 June 2005 00:53, Dave Robillard wrote:
Not to mention being more-or-less fully debugged and stable.
I think it's important to preserve some balance here. While absolute speed is
important, there are times when it can be a perfectly valid design decision
to subordinate speed to other goal (such as design flexibility,
maintainability or even [gasp!] speed of development). Will it really make
that much difference if a constructor that runs once at application startup
takes 0.75 instead of 0.20 sec to complete?
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 code is
important -- it highlights spots where the 'spit-n-shine' routine will do the
most good.
Cheers!
|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Director of Broadcast Software Development |
| | Salem Radio Labs |
|-------------------------------------------------------------------------|
| Optimization is fifteen percent science and eighty-five percent |
| black magic. |
| -- Linux Torvalds |
|-------------------------------------------------------------------------|
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? :) 
10:47 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 code is
important -- it highlights spots where the 'spit-n-shine' routine will do the
most good.
and then there's the general situation of architectural
flexibility. there is a lot of code in Ardour that is no doubt way
slower than its equivalent in SAWstudio, a hand-written 90% assembler
DAW. But in a program whose development lifetime spans a 7-9 fold
speedup in raw processor speed, would you rather have a software
architecture that is malleable, flexible and generally
arbitrary-limit-free, or one coded for a specific idea of what
"reasonable" and that runs very fast? For myself, I'll happily leave
the work of making things blazingly fast to AMD and Intel, and focus
my attention on algorithmic design and flexible architecture.
--p
12:36 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Fred Gleason <fredg(a)salemradiolabs.com> writes:
On Monday 06 June 2005 00:53, Dave Robillard wrote:
Not to mention being more-or-less fully debugged and stable.
I think it's important to preserve some balance here. While absolute speed is
important, there are times when it can be a perfectly valid design decision
to subordinate speed to other goal (such as design flexibility,
maintainability or even [gasp!] speed of development). Will it really make
that much difference if a constructor that runs once at application startup
takes 0.75 instead of 0.20 sec to complete?
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 :-).
And, even start up time counts, I find programs that need a long
time to start anoying, and LONG is a very subjective number :-).
As a console user, I am still not used to waiting after
I hit RETURN. Long life the savings from NOT having a GUI :-)
--
CYa,
Mario
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? :)
1:38 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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
:-).
Actually, it's an *engineering* argument. Technology design is full of
situations where getting the last 5% of a given possible performance can end
up costing 500% more than getting the original 95% did. This is called the
'law of diminishing returns'. The principle is much, *much* wider than just
computer application design.
And, even start up time counts, I find programs that
need a long
time to start anoying, and LONG is a very subjective number :-).
I would too, although I personally don't know that I'd call 3/4 sec a LONG
time to initialize a GUI application. The point I was trying to make is that
tradeoffs are part of the very warp and woof of the design process, and it's
impossible to develop anything efficiently without taking due cognizance of
that fact. Given the choice between spending a day adding a significant new
feature to an application or spending the same amount of time reducing that
application's start-up delay from 3/4 to 1/4 sec, I'll go for the first
option every time. Remember, *coding time* is your ultimate resource as a
programmer -- you want to invest it where you'll get you the biggest bang for
the buck.
Cheers!
|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Director of Broadcast Software Development |
| | Salem Radio Labs |
|-------------------------------------------------------------------------|
| Nothing ever becomes real till it is experienced -- even a proverb is |
| no proverb to you till your life has illustrated it. |
| -- John Keats |
|-------------------------------------------------------------------------|
7 Jun
7 Jun
12:02 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Mon, 2005-06-06 at 10:38, Fred Gleason wrote:
On Monday 06 June 2005 10:37, Mario Lang 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 costs the user 3/4 of a second in application
time would you consider that a good tradeoff? Not if you have over 100
users and they're having to deal with that 3/4 of a second 20 or so
times a day, every day for a year. Remember, it's only hard for you to
program it correctly once - it's a PITA for the user many times a day.
Jan
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
:-).
Actually, it's an *engineering* argument. Technology design is full of
situations where getting the last 5% of a given possible performance can end
up costing 500% more than getting the original 95% did. This is called the
'law of diminishing returns'. The principle is much, *much* wider than just
computer application design.
And, even start up time counts, I find programs
that need a long
time to start anoying, and LONG is a very subjective number :-).
I would too, although I personally don't know that I'd call 3/4 sec a LONG
time to initialize a GUI application. The point I was trying to make is that
tradeoffs are part of the very warp and woof of the design process, and it's
impossible to develop anything efficiently without taking due cognizance of
that fact. Given the choice between spending a day adding a significant new
feature to an application or spending the same amount of time reducing that
application's start-up delay from 3/4 to 1/4 sec, I'll go for the first
option every time. Remember, *coding time* is your ultimate resource as a
programmer -- you want to invest it where you'll get you the biggest bang for
the buck.
12:18 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 costs the user 3/4 of a second in application
time would you consider that a good tradeoff? Not if you have over 100
users and they're having to deal with that 3/4 of a second 20 or so
times a day, every day for a year. Remember, it's only hard for you to
program it correctly once - it's a PITA for the user many times a day.
I sort of agree, with the very large caveat that "once" is unlikely.
The time to write the code is often dwarfed by the time to maintain
the code. So your optimizations had damn well better be as readable
as you can make them, and well-commented.
--
Paul Winkler
http://www.slinkp.com
6 Jun
6 Jun
11:35 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Sun, 2005-06-05 at 23:53, Dave Robillard wrote:
On Sun, 2005-05-06 at 05:14 -0500, Jan Depner wrote:
C arrays dynamically resize easily (with realloc), are just as
simple to work with, and they're way faster. I'll take efficiency over
ease of use in most cases.
On Sun, 2005-06-05 at 08:08, fons adriaensen
wrote:
Because they dynamically resize, easily, and are generally much simpler
to work with, perhaps? :)
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. Not that C++ doesn't still suck..
I actually like C++ for some things but you should always try to use
the best tool for the job. In most cases I prefer C.
Jan
7 Jun
7 Jun
10:24 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Mon, 2005-06-06 at 15:45 -0500, Jan Depner wrote:
On Sun, 2005-06-05 at 23:53, Dave Robillard wrote:
- No (optional) bounds checking
- Not even remotely as simple to work with for many things (ie
vector.push_back(foo), the various inserting & removing functions ...
Vectors are really much, much more convenient.
- "Way faster" is a bit vague. vector[2] and array[2] will perform the
exact same operation, assuming you have optimization on
"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 high-level operations
in time critical code.
It's like arguing about, say, assembly vs. perl. Anyone who says one
side is (always) "better" is automatically wrong. :)
-DR-
On Sun, 2005-05-06 at 05:14 -0500, Jan Depner
wrote:
C arrays dynamically resize easily (with realloc), are just as
simple to work with, and they're way faster. I'll take efficiency over
ease of use in most cases. On Sun, 2005-06-05 at 08:08, fons adriaensen
wrote:
Because they dynamically resize, easily, and are generally much simpler
to work with, perhaps? :)
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.
8 Jun
8 Jun
3:23 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Tue, 2005-06-07 at 19:20, Dave Robillard wrote:
On Mon, 2005-06-06 at 15:45 -0500, Jan Depner wrote:
True. I usually try to use the right tool for the job.
Unfortunately, with the data I work with, the right tool is almost
always the fastest tool.
Jan
On Sun, 2005-06-05 at 23:53, Dave Robillard
wrote:
- No (optional) bounds checking
- Not even remotely as simple to work with for many things (ie
vector.push_back(foo), the various inserting & removing functions ...
Vectors are really much, much more convenient.
- "Way faster" is a bit vague. vector[2] and array[2] will perform the
exact same operation, assuming you have optimization on
"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 high-level operations
in time critical code.
It's like arguing about, say, assembly vs. perl. Anyone who says one
side is (always) "better" is automatically wrong. :)
On Sun, 2005-05-06 at 05:14 -0500, Jan Depner
wrote:
C arrays dynamically resize easily (with realloc), are just as
simple to work with, and they're way faster. I'll take efficiency over
ease of use in most cases. 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 they dynamically resize, easily, and are generally much simpler
to work with, perhaps? :)
6:50 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Tue, 2005-06-07 at 19:34 -0500, Jan Depner wrote:
On Tue, 2005-06-07 at 19:20, Dave Robillard wrote:
You must be working with relatively large amounts of relatively simple
data then.
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 benefit from this super performance boost.
Aha! Here's a vector of 5,000 oscillator structures, and it takes 5
seconds to initialise them all. Switch to using an array and... erm...
now it only takes 4.995 seconds to initialise them all.
I'm sure my users will notice and appreciate the 5ms saving, but I
suspect I could have served them better by looking at where my code was
actually spending most of its time before trying to "optimise" it.
Cheers
Simon
[1] It really was a generous assumption: I've assumed that arrays are
*infinitely* faster than vectors in this example.
"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 high-level operations
in time critical code.
It's like arguing about, say, assembly vs. perl. Anyone who says one
side is (always) "better" is automatically wrong. :)
True. I usually try to use the right tool for the job.
Unfortunately, with the data I work with, the right tool is almost
always the fastest tool.
7:07 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 benefit from this super performance boost.
Aha! Here's a vector of 5,000 oscillator structures, and it takes 5
seconds to initialise them all. Switch to using an array and... erm...
now it only takes 4.995 seconds to initialise them all.
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 start_. It takes no more time or effort than using a vector.
--
FA
9:19 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 start_. It takes no more time or effort than using a vector.
two comments. one is a repeat, because i don't think my original
message made it through from several days ago. the repeat is only
vaguely related to this post.
a) (the new one) sometimes you simply *don't* know whether you need the
random access of a C array or the properties of a singly-linked list
or the properties of a doubly-linked list, let alone the additional
heuristics of a set, a FIFO queue etc. 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<Foo> Foos;
to
typedef list<Foo> Foos;
or some other STL container. 95% of the time, thats the only change in
the code i have to make. if you really know and understand all the
parameters of the software design up front, this isn't useful, but i
haven't written a single piece of software where this claim was true :)
b) (repeat) i have no doubt that there are many areas where ardour
(for example) contains code much, much slower than the equivalent in
SAWstudio, which is written in 90%+ assembler. however, on a project
whose development alone takes many years and has seen a 7-9 fold speed
up in processor speeds, i would rather concentrate on algorithmic
design (for example, avoiding silly arbitrary limits, ensuring maximal
flexibility even if its not intended to be exposed to the user
etc). i'll leave "making things as fast as possible" to intel, AMD and
the gcc team.
--p
9:58 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Paul Davis <paul(a)linuxaudiosystems.com> 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 :-)
maarten
10:08 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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<Foo> Foos;
to
typedef list<Foo> Foos;
or some other STL container. 95% of the time, thats the only change in
the code i have to make.
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 matter
much.
if you really know and understand all the
parameters of the software design up front, this isn't useful, but i
haven't written a single piece of software where this claim was true :)
Don't tell me you've been switching ardour's audio buffers between vectors
and lists ... :-)
b) (repeat) i have no doubt that there are many areas
where ardour
(for example) contains code much, much slower than the equivalent in
SAWstudio, which is written in 90%+ assembler. however, on a project
whose development alone takes many years and has seen a 7-9 fold speed
up in processor speeds, i would rather concentrate on algorithmic
design (for example, avoiding silly arbitrary limits, ensuring maximal
flexibility even if its not intended to be exposed to the user
etc). i'll leave "making things as fast as possible" to intel, AMD and
the gcc team.
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.
As to assembler, I've no problem with it per se - you can write well
structured object oriented code even in assembly. I think it's use is
warranted in two cases:
- It makes a significant difference in speed, and this is important,
- The algorithm can be expressed more clearly or easily in assembler
than in any high level language. [1]
In both cases, we're probably talking about small routines anyway.
[1] This includes the case where you can't write it in C at all. For
example we're using here a very small RT 'nanokernel' running on the
ARM for our embedded applications. It's less than 100 statements, and
none of it could ever be written in C. Yet the API is entirely made
up of C++ classes (threads, message boxes, semaphores,...) and there
is virtually nothing in between the two.
--
FA
11:12 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 about small
routines anyway.
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.
--p
12:40 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 notation
app). It was written for the Acorn Archimedes and IIRC 100% assembly.
But then, ARM assembly is fun...
--
FA
9 Jun
9 Jun
1:40 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 years ago at
NAB. Brilliant guy. SAW was one of the very first multitrack DAWs for PCs,
and is indeed written almost entirely in x86 assembly. The original target
platform was high-end 386 and 486 systems, and I can personally testify that
it performed very well on those boxes. This was back when a 1 GB SCSI drive
could run well over $2000 US. I suspect that Bob's choice of assembly was
driven by a very practical need: it was the only way to achieve acceptable
performance on the available hardware of the day. As such, it was a
perfectly reasonable design tradeoff.
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 something that could be made to work
quite acceptably in a higher-level language. It's all about balance. To be
sure, different designers will choose different tradeoffs between
speed/efficiency/maintainability, but that's to be expected. This is an area
where the *science* of application design blends imperceptibly into the
*art*.
Cheers!
|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Director of Broadcast Software Development |
| | Salem Radio Labs |
|-------------------------------------------------------------------------|
| A rock pile ceases to be a rock pile the moment a single man |
| contemplates it, bearing within him the image of a cathedral. |
| -- Antoine de Saint-Exupery |
|-------------------------------------------------------------------------|
6:03 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 something that could be made to work
quite acceptably in a higher-level language.
Mmm, yes ... But wouldn't it be nice to have systems that actually *do*
magnitudes more powerful stuff, instead of just doing what they have
always done?
More than 90% of the (running) time is spent in the innermost loops. And
as it happens, the innermost loops are also (considerably) less than 10%
of the codebase.
Me thinks these loops are still candidates for some agressive, take no
prisoners optimizations, no? Especicially given that vectorising can
give a fourfold (or more?) speedup.
OpenGL, FFT, reverb, you name it ... These are all commodities that we
take for granted. But somebody have to write them also, so that we can
actually use them as commodities.
Oh well. Except for the "multiline inline asm" thingie, gcc still works
just fine for me.
mvh // Jens M Andreasen
8 Jun
8 Jun
5:09 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Wed, 2005-06-08 at 14:08 +0200, Alfons Adriaensen wrote:
Using C++ and/or templates doesn't necessarily make anything any slower,
but improves readability.
For example, if you would like to multiply some dataset with window...
With libDSP you can do:
typedef float sample_t;
clDSPVector<sample_t> vData;
clDSPVector<sample_t> vWindow;
vWindow.WinHamming(1024);
...
vData.Set(pSrcBuf, 1024);
vData *= vWindow;
This would perform the multiply using handwritten asm SIMD routines.
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 equally fast by changing the operator[]
implementation.
I think the above is much clearer and faster to use than calling equal C
functions (which also exist). And you can easily change it to use
doubles instead of floats just by changing the typedef.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
typedef
list<Foo> 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 matter
much.
6:35 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 equally fast by changing the operator[]
implementation.
I wanted to make sure that this thing is clear, so I'll clarify it even
further.
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.
Except that the template automatically resizes, is aligned to
architecture optimal boundary size, automatically selects asm SIMD
optimizations for current runtime architecture, etc.
#include <dsp/DSPVector.hh>
template <class TOwnVector_t> class clOwnVector :
public clDSPVector<TOwnVector_t>
{
public:
TOwnVector_t & operator[] (size_t uIndex)
{
return (clDSPVector<TOwnVector_t>::GetRawPtr()[uIndex]);
}
};
int main (int argc, char *argv[])
{
float fpInit[] = { 1.0f, 2.0f, 3.0f, 4.0f, 5.0f };
clOwnVector<float> vecOwn;
vecOwn.Put(fpInit, 5);
vecOwn *= vecOwn;
printf("%g %g %g %g %g\n",
vecOwn[0],
vecOwn[1],
vecOwn[2],
vecOwn[3],
vecOwn[4]);
return 0;
}
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
6:40 p.m.
New subject: [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 if the template or C array is used.
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?
Chris
6:56 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Wed, 2005-06-08 at 21:41 +0100, Chris Cannam wrote:
On Wednesday 08 Jun 2005 21:35, Jussi Laako wrote:
Abovementioned template is not based on STL... About the STL; there are
number of different implementations of std::vector<> in different C++
RTLs, so one cannot expect anything specific except the interface from
it. It may, or may not, be slow, but it's not C++'s fault.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
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, after they changed
vector from an array to a real class in gcc 3.3 or whenever it was?
7:07 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Wednesday 08 Jun 2005 21:56, Jussi Laako wrote:
On Wed, 2005-06-08 at 21:41 +0100, Chris Cannam
wrote:
Oh, I'm sorry -- I was ploughing through this thread and just replying
to something with "vector" in it. I do apologise.
It certainly is possible to write extremely efficient classes in C++,
and in many cases they may be likely to be better than the code that
people would write in C (because you can encapsulate best practice in a
method that people would [often rightly] be averse to writing in the
context of C code). Of course the reverse is also true.
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 on STL... About the STL; there are number of different
implementations of
std::vector<> in different C++ RTLs
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.
Chris
9 Jun
9 Jun
5:40 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 array (i.e. contigous), the [] operator
compiles to the C equivalent when optimisation is turned on. The result
is the same as a C array.
Thinking about it logically, why would the developers of a C++ standard
library choose a different method? The std::vector is meant to be the
C++ replacement to C arrays, so a slow down in speed would effectively
render it useless.
However, last time I checked, GCC does not inline functions with -02
(only with -O3), so I always specify -finline-functions when compiling.
8 Jun
8 Jun
6:57 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 with almost everything
he says. But what is 'optimization' ?
When I choose to use a plain C aray instead of a vector, that is
*not* optimization, but a design choice.
In his books Knuth does not use any fancy high level programming
language to explain or demonstrate an algorithm. The language he
uses is something between assembly and C, and he has some very
good reasons for doing this (they are explained in the first book
IIRC).
There is a lot of 'optimization' going on and being discussed,
not of how something is expressed, but of the algorithms
themselves. So this happens even *before* coding, and qualifies
as 'very early optimization' :-). Apparently there's no evil here.
It's my experience that if you study your algorithms a bit before
you start coding, then very often the fancy high level stuff is not
needed and it just gets in the way.
Using C arrays and strings for no reason when a much
more robust
higher level type would suffice...
To me this sounds like "using 1 kg of dynamite when 100 kg would
suffice..."
--
FA
5 Jun
5 Jun
1:19 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Es geschah am Sonntag 05 Juni 2005 14:12 als Erik de Castro Lopo schrieb:
Christian Schoenebeck wrote:
Exactly, that's why it's not a valid comparison. With equal code I doubt you
reach faster results with C vs C++ compilation nowadays. Usually they reach
equal performance (e.g. gcc vs. g++). Sometimes you can even reach slightly
better results with compiling the same code with g++ than with gcc due to
conservative "attitude" of gcc. But on the other hand you migh say, that the
latter could be fixed with CFLAGS, so that's why you can still consider their
results to be equal.
Another rumour (also claimed by the site above) is that Intel's compiler would
be faster than GCC. In various DSP benchmarks I made together with Vladimir
S., gcc 3.4's binaries outperformed most binaries build by icc. I have to
note: our focus was SIMD code. Maybe there are few general purpose sections
where icc does a better job than gcc, but being a multimedia developer of
course I'm keen that the code section which is executed the most is as fast
as possible - and that's still the proporional tiny DSP code.
CU
Christian
Es geschah am Sonntag 05 Juni 2005 04:18 als Erik
de Castro Lopo schrieb:
Not my claim. The claim is here:
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&s…
cpu
I believe that this shootout is somewhat flawed in that the examples
are all relatively short pieces of code unlike anything that even
approaches real world code.
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:z
http://shootout.alioth.debian.org/benchmark.php?test=wc&lang=icpp&i…
=fullcpu
while the C version uses standard C arrays:
http://shootout.alioth.debian.org/benchmark.php?test=wc&lang=icc&id…
fullcpu
Are you surprised that C arrays are faster than std::vector? 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 puts Ocaml compiled to native binaries as faster
than C++ but slower than C.
Hooo, that is a very brave claim,
11:02 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
[Erik de Castro Lopo]
Tim Goetze wrote:
I readily admit I'm a fool, but I must insist that the g++ developers
are fools just the same (albeit of different caliber), even if that
offers me little consolation.
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 unspecified/undocumented characteristics will remain
the same across versions is asking for trouble. Well I really like to separate the C and C++. C is
unashamedly a
low level language. C++ OTOH tries to be both low level and high
level. In comparison to C, C++ is a poor low level language.
Compared to Python or Ocaml, C++ is a poor high level language.
C++ for all practical purposes simply does what I want and gives me
low-level control where I need it. I've never looked at -S output and
found that C would surely and significantly improve the output, it
was just what I expected and accepted.
The flaws I find with C++ are not with the language itself, I find
them clearly with the fickle gcc implementation. That's not to say
your point of view isn't valid, rather it is one I rarely if ever
assume.
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.
A very valid point given your preferences; however what you perceive
as Python's flaws (most prominently easily provoked runtime errors) I
lightheartedly accept as necessary consequences of the language's open
and simple-minded character that I hold so dear.
I have done some seriously difficult code in Ocaml;
tasks that in
C or C++ would a nightmare of complexity and/or endless futzing
about with trivial minor details. It is not the ideal programming
language, but for some kinds of tasks it beats every other
programming language I've ever seen.
I can imagine it will be the closest to perfect solution in some
(maybe even many) circumstances and that it could be a welcome tool
for me too; however I'm pretty much sold on Python as my high-level
language of choice and very reluctant to diversify in computer
language literacy any further.
Cheers, Tim
7:15 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 libDSP which is written is C++ and contains
inline asm. I haven't had any big problems with new compiler versions
and the code has gone through something like gcc-2.7.x to gcc-4.x. And
actually gcc-3.x was the first one which had really working C++
compiler. All of the 2.x series had broken exception handling.
Making any assumptions on compiler behaviour except those clearly stated
by the standard is dangerous. I usually compile the code using 3-4
different C++ compilers to verify it's functionality. Unfortunately the
inline asm parts have to be removed for some compilers, but those are
architecture specifics anyway and always have a pure C++ implementations
also.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
6 Jun
6 Jun
5:37 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 base type is in C which doesn't know about
vtables.
There are no memory layout guarantees for non-POD types.
If your external functions use the correct type (i.e., a pointer to
the base type), the compiler will automatically cast class pointers in
the correct way. Otherwise, you have to cast to the base type
yourself whenever you 'export' a pointer.
Enter gcc version 4, which requires the templated
types' constructor
code be rewritten in the most nonsensical, misleading and ugly fashion
possibly imaginable this side of Hungary and Redmond, WA, according to
our (now not so very young anymore) hero.
Could you show some details? Probably the old code wasn't quite
correct according to The Standard(TM).
Regards,
Clemens
6:48 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
[Clemens Ladisch]
Tim Goetze wrote:
May compile fine, but like this a 100-line __asm__ goes well beyond my
pain threshold when it comes to readability and maintainability.
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");
} If your external functions use the correct type (i.e.,
a pointer to
the base type), the compiler will automatically cast class pointers in
the correct way. Otherwise, you have to cast to the base type
yourself whenever you 'export' a pointer.
Believe me I have tried to come up with sensible solutions but there's
quite a lot more to it than just fixing a few thousand pointer casts.
Basically, you can't rectify the problem because the basic Python
Object type (from which my types are derived) is actually at a fixed
offset into a Python garbage-collected structure. You can't just slip
in a vtable, in fact you can't slip in anything at all; neither is it
possible to alternatively (and pointlessly to be sure) prefix the
Python GC structure with a vtable without rewriting Python itself.
Could you show some details? Probably the old code
wasn't quite
correct according to The Standard(TM).
What I have is this (from caps code):
class DescriptorStub
: public LADSPA_Descriptor
{
/* just a constructor and destructor here */
};
template <class T>
class Descriptor
: public DescriptorStub
{
public:
Descriptor()
{ setup(); }
void setup();
...
};
The following is OK for an older g++:
void
Descriptor<AmpIV>::setup()
{
UniqueID = 1794;
...
}
but g++ since 4.0 wants this instead:
template <> void
Descriptor<AmpIV>::setup()
{
...
}
I cannot for the life of me imagine a good reason why "template <>"
should be necessary. "setup()" was never declared as a template, let
alone one with an empty template parameter.
If this is indeed prescribed by the language standard, I'll have a
very, very hard time getting over it.
It may not look like much but you have to understand that to me coding
is also an exercise in aesthetics.
Cheers, Tim
9:31 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Tim Goetze wrote:
I assumed your objects should just be accessed from Python, but it's
of course different if they are to be managed by Python.
You could introduce an additional layer of indirection: hold a
separate C++ object with a pointer from the Python-managed object.
[Clemens Ladisch]
You mean you want to omit \n and the quotes? That was always invalid
in both C and C++.
Tim Goetze wrote:
May compile fine, but like this a 100-line __asm__ goes well beyond my
pain threshold when it comes to readability and maintainability. 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"); If your
external functions use the correct type (i.e., a pointer to
the base type), the compiler will automatically cast class pointers in
the correct way. Otherwise, you have to cast to the base type
yourself whenever you 'export' a pointer.
Believe me I have tried to come up with sensible solutions but there's
quite a lot more to it than just fixing a few thousand pointer casts.
Basically, you can't rectify the problem because the basic Python
Object type (from which my types are derived) is actually at a fixed
offset into a Python garbage-collected structure. The following is OK for an older g++:
void
Descriptor<AmpIV>::setup()
{
UniqueID = 1794;
...
}
but g++ since 4.0 wants this instead:
template <> void
Descriptor<AmpIV>::setup()
{
...
}
I cannot for the life of me imagine a good reason why "template <>"
should be necessary.
It's needed because
A) the standard says so;
B) Descriptor is still a template, even if all template parameters
happen to be specialized.
"setup()" was never declared as a template,
let alone one with an
empty template parameter.
I guess you don't want to hear it, but if setup() was declared as a
template, you would have to write something like this:
template <> template <class T> void
Descriptor<AmpIV>::setup<T>()
{ ... }
If this is indeed prescribed by the language standard,
I'll have a
very, very hard time getting over it.
For completely specialized templates, you can avoid the "template<>"
stuff like this:
typedef Descriptor<AmpIV> Amp4Descriptor; // no "template" needed here
void Amp4Descriptor::setup() {...}
It may not look like much but you have to understand
that to me
coding is also an exercise in aesthetics.
"aesthetics" is not a keyword in C++. ;-)
Regards,
Clemens
10:30 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
[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 could introduce an additional layer of
indirection: hold a
separate C++ object with a pointer from the Python-managed object.
Been there, done that. So far the next best thing, but too substantial
a change for the project in question, and intolerably inconvenient in
any context.
For completely specialized templates, you can avoid
the "template<>"
stuff like this:
typedef Descriptor<AmpIV> Amp4Descriptor; // no "template" needed here
void Amp4Descriptor::setup() {...}
This is at least more readable than "template <>". It's still plain
stupid to have to write. The version I prefer is already unambiguous,
why should one have to add anything?
I trust you got that right and it's in fact a C++ standard
requirement; in that case I guess I'll have to sadly write the whole
thing off as a case of language lawyer madness.
"aesthetics" is not a keyword in C++. ;-)
Thought so :) but in the end it is what makes looking at code bearable
for me.
Cheers, Tim
11:17 a.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Tim Goetze wrote:
[Clemens Ladisch]
It's a gcc extension so^H^Hfor compatibility with some old Unix
compilers that accidentally allowed it. AFAIK it was dropped from g++
but not gcc because those old compilers didn't know about C++ anyway.
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.
This issue is at a lower level, i.e., how to parse string literals.
Regards,
Clemens
1:05 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
Es geschah am Montag 06 Juni 2005 15:17 als Clemens Ladisch schrieb:
Tim Goetze wrote:
At least in g++ 3.4 this *feature* is still present. I remember a painful asm
debugging session where some registers went mad. The reason was I merged
couple of individual asm template sequences and forgot to place a \n at some
seam points and those instructions were simply ignored.
Lesson: always but a \n after asm template instructions, even or especially
after the last asm instruction.
CU
Christian
[Clemens Ladisch]
It's a gcc extension so^H^Hfor compatibility with some old Unix
compilers that accidentally allowed it. AFAIK it was dropped from g++
but not gcc because those old compilers didn't know about C++ anyway. 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"
4:48 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Mon, 2005-06-06 at 10:43 +0200, Tim Goetze wrote:
<snip/>
What I have is this (from caps code):
class DescriptorStub
: public LADSPA_Descriptor
{
/* just a constructor and destructor here */
};
template <class T>
class Descriptor
: public DescriptorStub
{
public:
Descriptor()
{ setup(); }
void setup();
...
};
The following is OK for an older g++:
void
Descriptor<AmpIV>::setup()
{
UniqueID = 1794;
...
}
but g++ since 4.0 wants this instead:
template <> void
Descriptor<AmpIV>::setup()
{
...
}
I cannot for the life of me imagine a good reason why "template <>"
should be necessary. "setup()" was never declared as a template, let
alone one with an empty template parameter.
If this is indeed prescribed by the language standard, I'll have a
very, very hard time getting over it.
It may not look like much but you have to understand
that to me coding
is also an exercise in aesthetics.
Then perhaps you shouldn't be cracking this little nut with the
sledgehammer of template specialisation, regardless of whether g++ used
to supply a non-standard one with a shorter handle? ;)
How about adding the unique IDs as static member constants to AmpIV and
its brethren like this:
class AmpIV {
...
public:
static const unsigned UniqueID = 1794;
...
};
...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.
Cheers
Simon
8 Jun
8 Jun
7:13 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
[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 think I have a nice
solution in mind now. Until I have a major addition to make to the
package I'm too lazy to hack away at it though. :)
Cheers, Tim
6 Jun
6 Jun
12:43 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
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 reason was for dropping midithing.
I played with it briefly and quite liked it. Sad indeed.
btw, the links leading through these series of pages
have a certain comical value:
http://www.quitte.de/midithing.html
"The Thing is dead!" ... "Something much better" at:
http://www.quitte.de/mandala.html
"Rechristened ... Please go to the nam page for the latest info on this
package."
http://www.quitte.de/nam.html
"Superseded: Please look at the milk project instead."
http://www.quitte.de/milk.html
Leading me to wonder, how long before Milk is superceded, or at
least renamed? ;-)
I usually just drop my projects completely after one pre-release.
I greatly admire your tenacity :-)
--
Paul Winkler
http://www.slinkp.com
1:23 p.m.
New subject: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
[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
superceded, or at
least renamed? ;-)
Already all but dead ... :)
I usually just drop my projects completely after one
pre-release.
I greatly admire your tenacity :-)
Thanks! Actually there's just three projects in four guises, but I get
a good laugh out of it as well sometimes. Realizing you're a fool sets
you free! :)
For the record, I made a few pieces I like a lot with all of those
projects, and one of them served as a development environment and
testbed for the DSP code you now find in the caps package. It's still
in active use but will ultimately wane.
Cheers, Tim
7103
days inactive
7108
days old
linux-audio-dev@lists.linuxaudio.org
56 comments
22 participants
participants (22)
-
Alfons Adriaensen -
allan_wind＠lifeintegrity.com -
Chris Cannam -
Christian Schoenebeck -
Clemens Ladisch -
Dave Robillard -
David Cournapeau -
Erik de Castro Lopo -
fons adriaensen -
Fred Gleason -
Ignacio Ramírez -
Jack O'Quin -
Jan Depner -
Jens M Andreasen -
Jussi Laako -
Maarten de Boer -
Mario Lang -
N Smethurst -
Paul Davis -
Paul Winkler -
Simon Jenkins -
Tim Goetze