10 Apr
2004
10 Apr
'04
12:15 p.m.
Jan Depner:
Thats not what I said. Or ment at least. I said; use a high-level language
for high-level operations. I'm not saying: Do computer-intensive/realtime
critical operations with lisp/python/ruby/etc. Ardour consist of about
90% GUI code, if I have understood correctly. Those 90% of code could
have been written in a more high-level language with garbage collectors,
proper list-functions, dynamic typing and other helpful things c++ does
not provide because C++ is supposed to be extremely fast, allways.
Or in case not, why not?
--
Why on earth
use C++? Use a desent high-level non-crippled language like
lisp, python or ruby. The lowlevel stuff must of course be written in
c/c++ or something, but only a very small amount of multitracker-code is
that low-level. Yes, I have made _huge_ programs in C myself, but that was
only because I was so damned inexperienced and had so damned slow machine
to work on at the time.
Today, where there are so many descent libraries for
lisp/python/ruby/ada(?)/etc(?), and the machines are so fast,
as good as no one should use c++ for high-level things. You'll
waste time.
Yes, this might start a flame-war, but I really think people
should be aware of the C/C++-stupidness.
Audio is inherently computationally intensive. So your answer to those
who have slower machines is "buy better hardware because I don't want to
bother writing in a language that is fast enough to work on your
system"? This isn't a flame it's just that I don't understand why you
consider C/C++ stupid. They have their place. I work on scientific
applications and I guess I could use Perl or Python or (shudder) MATLAB
(if you can consider that a language) but I don't because they're too
slow. Where I work we have a supercomputer (currently at #18 on the top
500) and we have applications coded in (again, shudder) FORTRAN. Why?
Because it's faster than C or C++ on supercomputers. It's better at
parallel processing. I did FORTRAN programming for 14 years before I
switched to C (yes, I'm _that_ old). I've also programmed in COBOL,
BASIC, three or four different assembly languages, Pascal, Java, you
name it. They all have their place. I just don't get this "my language
is better than your language" stuff (with the possible exception of ADA
;-)
10 Apr
10 Apr
1:08 p.m.
New subject: [linux-audio-dev] Anyone planned a GTK2-based Multitracker?
On 04/10/04 12:08:31, Kjetil Svalastog Matheussen wrote:
Thats not what I said. Or ment at least. I said; use a
high-level language
for high-level operations. I'm not saying: Do computer-intensive/realtime
critical operations with lisp/python/ruby/etc. Ardour consist of about
90% GUI code, if I have understood correctly. Those 90% of code could
have been written in a more high-level language with garbage collectors,
proper list-functions, dynamic typing and other helpful things c++ does
not provide because C++ is supposed to be extremely fast, allways.
Or in case not, why not?
C++ (with the STL) has some pretty darn useful list functions. It's not as
low level and sucked down as you seem to think....
Personally, I'd rather have that 90% of Ardour be nice and quick. I don't
care what anyone says, GUIs written in scripting language are noticably slower
than GUIs written in a compiled language like C or C++.
-Dave
1:24 p.m.
New subject: [linux-audio-dev] Anyone planned a GTK2-based Multitracker?
On Sat, 2004-04-10 at 11:08, Kjetil Svalastog Matheussen wrote:
Jan Depner:
Thats not what I said. Or ment at least. I said; use a high-level language
for high-level operations. I'm not saying: Do computer-intensive/realtime
critical operations with lisp/python/ruby/etc. Ardour consist of about
90% GUI code, if I have understood correctly. Those 90% of code could
have been written in a more high-level language with garbage collectors,
proper list-functions, dynamic typing and other helpful things c++ does
not provide because C++ is supposed to be extremely fast, allways.
Or in case not, why not?
--
Ah, good point. However, the SLab GUI is written in Tcl/Tk and it just
doesn't cut it because the GUI can't keep up. It's _very_ nice but
extremely limited. Granted, Tcl/Tk is not Python but you get the idea.
I have run a few experiments with Ardour. The most interesting being to
record 8 tracks at 24/96 on my system with the GUI being local and
remote. I use blackbox and cut the graphics overhead to the bare
minimum. When I run locally I get a few xruns. When I run with a
remote GUI (X windows, 100Mb ethernet) I get no xruns. The graphics
overhead that is offloaded to the other X server has a huge impact on
the recording. The problem that you aren't addressing is that the GUI
uses up a significant portion of the computational resources. You want
everything on your system to run as fast as possible, not just the
"critical operations". Take a look at how much of the system is used by
the GUI in JAMin for instance.
Jan
Why on
earth use C++? Use a desent high-level non-crippled language like
lisp, python or ruby. The lowlevel stuff must of course be written in
c/c++ or something, but only a very small amount of multitracker-code is
that low-level. Yes, I have made _huge_ programs in C myself, but that was
only because I was so damned inexperienced and had so damned slow machine
to work on at the time.
Today, where there are so many descent libraries for
lisp/python/ruby/ada(?)/etc(?), and the machines are so fast,
as good as no one should use c++ for high-level things. You'll
waste time.
Yes, this might start a flame-war, but I really think people
should be aware of the C/C++-stupidness.
Audio is inherently computationally intensive. So your answer to those
who have slower machines is "buy better hardware because I don't want to
bother writing in a language that is fast enough to work on your
system"? This isn't a flame it's just that I don't understand why you
consider C/C++ stupid. They have their place. I work on scientific
applications and I guess I could use Perl or Python or (shudder) MATLAB
(if you can consider that a language) but I don't because they're too
slow. Where I work we have a supercomputer (currently at #18 on the top
500) and we have applications coded in (again, shudder) FORTRAN. Why?
Because it's faster than C or C++ on supercomputers. It's better at
parallel processing. I did FORTRAN programming for 14 years before I
switched to C (yes, I'm _that_ old). I've also programmed in COBOL,
BASIC, three or four different assembly languages, Pascal, Java, you
name it. They all have their place. I just don't get this "my language
is better than your language" stuff (with the possible exception of ADA
;-)
6:56 p.m.
New subject: [linux-audio-dev] Anyone planned a GTK2-based Multitracker?
On Sat, Apr 10, 2004 at 06:08:31PM +0200, Kjetil Svalastog Matheussen wrote:
Thats not what I said. Or ment at least. I said; use a
high-level language
for high-level operations. I'm not saying: Do computer-intensive/realtime
critical operations with lisp/python/ruby/etc. Ardour consist of about
90% GUI code, if I have understood correctly. Those 90% of code could
have been written in a more high-level language with garbage collectors,
proper list-functions, dynamic typing and other helpful things c++ does
not provide because C++ is supposed to be extremely fast, allways.
Or in case not, why not?
The nice thing about C++ is that it is 'low level' when you need that,
and that by writing a few classes on top of this you can get _exactly_
the type of high level abstraction that you need, without the ballast of
a high level language that is designed to provide everything to everybody.
This also applies to GUI code. You need only a few relatively simple classes
on top of Xlib that take care of event polling and delivery, X11 resource
management (an area where most high-level languages break down), and a set
of widgets. Everything else will probably need a general purpose canvas and
low level drawing operations anyway, and these are as easy to do directly in
X than in any toolkit or high level language that I know of, or even easier.
What you get is a high level interface, blazingly fast performance, and
easy integration with the time-critical code that is typical for any audio
application. Try to do that with Tcl/Tk, Python or whatever.
Just my 2 Eurocents, of course.
--
FA
7472
days inactive
7472
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
4 participants
participants (4)
-
Dave Robillard -
Fons Adriaensen -
Jan Depner -
Kjetil Svalastog Matheussen