Linux-Development-Sys Digest #910, Volume #6 Tue, 29 Jun 99 21:14:34 EDT
Contents:
Re: Why not C++ (Greg Comeau)
Re: Filesize larger than 2 GB on Intel machines an Linux 2.0.36 (Christopher Browne)
Re: Why not C++ (Greg Comeau)
Re: Getting a Soundblaster Live Value to work (Mark Evans Jeffcoat)
Re: Why not C++ (Greg Comeau)
Re: GLIBC 2.1.1: still problems in dynamic loader (latest patches (Roman Sulzhyk)
Where to find IOSTAT and SAR kernel patch? (Gopal Santhanam)
Re: Why we are still holding on to X Windows (Victor Wagner)
Sleeping or not? (herman)
Re: Why not C++ (Greg Comeau)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 29 Jun 1999 15:16:56 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Bruce Hoult)
writes:
>In article <[EMAIL PROTECTED]>, Johan Kullstam
><[EMAIL PROTECTED]> wrote:
>
>> [EMAIL PROTECTED] (Nathan Myers) writes:
>>
>> > Thomas Steffen <[EMAIL PROTECTED]> wrote:
>> > > C++ might not be a very elegant language, but it is
>> > >fast, at least compared to other OO languages.
>> >
>> > Its syntax isn't very elegant, but where did that come from?
>> > It's fast compared to _any_ language, period. People who say
>> > it's slower than (e.g.) C are just spreading FUD.
>>
>> C++ *is* slower than C. not by orders of magnitude or even a factor
>> of two, but if you feed code to both C and C++ compilers, the C
>> compiler will optimize harder and generally make a better product.
>> this is because C is more mature and that C++ code is potentially more
>> complex which causes a more conservative compile.
>
>I'd love to see an example of this.
>
>Given...
>
>1) code that is both valid C and valid C++, and
>2) a C++ compiler that compiles to C (e.g. AT&T CFront)
>
>... you will end up with identical machine code, no matter whether you
>compile with the C compiler, or compile with the C++ compiler (using the
>same C compiler as the back end).
It's not so much that you will get said but that you can
(and not just theoretically)
>You may be able to find some particular C++ compiler that produces worse
>code compiling a C program than some particular C compiler, but that is a
>function of the compiler, not the language.
And vice versa. Exactly.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Filesize larger than 2 GB on Intel machines an Linux 2.0.36
Reply-To: [EMAIL PROTECTED]
Date: Tue, 29 Jun 1999 23:54:00 GMT
On Tue, 29 Jun 1999 10:30:07 GMT, Kent Nilsen <[EMAIL PROTECTED]> wrote:
>I asked about it a while ago, and I got the answer that you have to use the
>loopback device. I don't know how that works, but I think it moved the size
>limit to 16 Gb or maybe 2 Tb, not sure.
ext2 is quite capable of handling *filesystem* sizes considerably larger
than 2GB. (2TB rings a bell.)
But mounting across a loopback device does not change the file
descriptor in LIBC. Growing to sizes > 2^31-1 requires an API change.
--
"Catapultam habeo! Nisi pecuniam omnem mihi dabis, ad caput tuum saxum
immane mittam !!" (I have a catapult! If you do not pay me the money
you owe me, I will hit you with a big rock !!)
-- Simon Gornall <[EMAIL PROTECTED]>
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/linuxkernel.html>
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking,comp.lang.c++
Subject: Re: Why not C++
Date: 29 Jun 1999 15:56:31 -0400
Reply-To: [EMAIL PROTECTED]
In article <7l4d4r$4is$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Linus
Torvalds) writes:
>In article <[EMAIL PROTECTED]>,
>Bruce Hoult <[EMAIL PROTECTED]> wrote:
>>
>>You may be able to find some particular C++ compiler that produces worse
>>code compiling a C program than some particular C compiler, but that is a
>>function of the compiler, not the language.
>[rest of Linus post snipped and moved below]
>Sometimes theory matters. Sometimes it doesn't. The world is not as
>simple as you make it out to be.
Since you've made it come down to your last words here, I'm compelled
to point out that your message has succeeded in simplifying things
_even more_ so than Bruce did. Furthermore, Bruce has some experience
with this matter, so he's not just talking in practice. So do I,
quite a lot in fact. Your comments are technically out of line.
I'm really surprised at your lax and clearly biased statements.
Let's revisit your statements:
>In theory, you're right.
In practice, this can be quite right too.
>In practice, C++ is a much more complex language.
This is not an in practice or not in practice thing, it's a reality:
C++ is more complex than C.
>As such, C++ compilers are much more complex beasts.
Probably. Something like that.
>And that is why some C++
>compilers do not generate as good code as the equivalent C compilers do.
NO, THAT IS NOT WHY. I cannot believe you are spreading such mythology.
Note too that many C++ compilers are also C compilers,
laced _right into_ the same exact compiler proper.
Let's see now. This MUST mean: some C compilers do not generate
as good code as themselves.
BTW, you are clearly comparing apples to oranges in your
_theoretical_ example. The reason why is because although we may
talk about equivalent C and C++ applications, it makes little sense
to talk about equivalent C and C++ compilers, certainly not at the
language level perspective itself. Clearly then this was either thrown
in as a red herring or is simply wrong do to poor wording or something.
The reason why some C++ compilers do not generate as good code as
some C compilers is the same reason why some C compilers do not generate
as good code as some C++ compilers, which turns out to be the same
reason why some C++ compilers do not generate as good code as some
other C++ compilers and also why some C compilers do not generate as good
code as some other C compilers. And that is because of the way the
authors wrote it. Now you may argue that C++ is so complex those
authors could not grok it. Well, this is not true across the board,
and no more so that some C compiler authors not grokking everything in C.
And anybody who thinks writing a C compiler is easy should spend the at
least 2 years or so it'll take to at least be baseline on a raw C compiler.
>In effect, what you're saying is "there is no theoretical reason why C++
>would be any slower than C". And you're right.
I can think of some theoretical reasons why C++ might be slower than
C in some areas. For instance, although a virtual function may be
faster than a hand-written switch statement, the comparison of say
exception handling vs some alternatives is not nearly so equivalent,
upon which C++ often would be slower in this isolated though granted
important area. But yes, this is true in practice for most of the
languages, and as some implementation show, true in reality too.
>But what others are saying is "a lot of existing C++ compilers generate
>worse code than a lot of existing C compilers". And they are right too.
Yes, see above. Perhaps those compiler writers just suck?
Or more to the point, perhaps the back end writers of the compiler just suck.
Anyway, clearly in your just made statement you are leaving open that
some C++ compilers generate better code than some C compilers.
So your remarks just don't follow.
>Sometimes theory matters. Sometimes it doesn't. The world is not as
>simple as you make it out to be.
You've made a grave technical mistake by assuming something more
complex must by nature have side-effects such as performance problems.
This is not inherent in complexity (though it is common).
Intuition is often wrong.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: [EMAIL PROTECTED] (Mark Evans Jeffcoat)
Crossposted-To: comp.os.linux.misc
Subject: Re: Getting a Soundblaster Live Value to work
Date: 29 Jun 1999 20:10:22 GMT
[EMAIL PROTECTED] wrote:
: Has anyone managed to do this at all? I've tried every logical compilation
: option I can think of with my 2.2.7 kernel but I just can't get the damn thing
: to make a peep. All I ever get is a "No such device" error when trying to
: access /dev/audio or /dev/dsp. I've had no luck with modules either.
:
Do the /dev/audio and /dev/dsp files actually exist? If not,
use the MAKEDEV script in /dev; do "/dev/MAKEDEV audio".
That's probably not the entire solution, but it's a
necessary step.
Mark Jeffcoat
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 29 Jun 1999 15:59:22 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Andi Kleen <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] (Nathan Myers) writes:
>
>> Andi Kleen <[EMAIL PROTECTED]> wrote:
>> >Well, the theory is that:
>> > int f(vector<vector<float> > array)
>> >is easier than
>> > int f(float **array)
>> >to handle for a beginner.
>
>[exercise in selective quoting to prove a point deleted]
>
>My point was simply:
>In my first tries to use the STL, I had to fight with 10+ lines
>really obscure template error messages. I wouldn't wish that to
>any poor beginner (given that beginning is usually mostly syntax
>error fixing at first)
We agree (at least I do), it can be obscure et al indeed.
However, the alternative IS NOT as rosey as you make it out to be.
It is often as obscure and sometimes worse so.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: Roman Sulzhyk <[EMAIL PROTECTED]>
Subject: Re: GLIBC 2.1.1: still problems in dynamic loader (latest patches
Date: Tue, 29 Jun 1999 20:24:54 +0000
This is a multi-part message in MIME format.
==============F2BCB5551F721926F8291184
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Andreas Jaeger wrote:
> >>>>> Roman Sulzhyk writes:
>
> > Hello:
>
> > I guess this is a to attention of Andreas Jaeger.
> Ok, here I am;-).
>
> > I have trouble isolating this into small enough case to submit a bug
> > report. Basically, if you get the socks5 package from
> > http://www.socks.nec.com/ and compile it as a shared preloadable
> > library to use with 'runsocks' (which essentially transparently
> > sockifies any app by wrapping network library calls) it does not
> > work. If you set LD_PRELOAD=/usr/local/lib/libsocks5_sh.so all
> > applications dump core. What I can deduce from setting LD_DEBUG=all
> > is that at some point the application starts to reload all (some?)
> > of dl_ symbols and dumps core soon afterwards. I'm attaching debug
> > output generated by dynamic loader.
> This might be ok. It has to resolve symbols for each library and for
> the program - and therefore symbols are mapped a number of times. It
> would be wrong if a symbol would be mapped two times for the same
> library. For example _dl_init_next is first resolved in ld-2.1.1.so
> and later in libc.so.6.
>
> You should try to debug this with gdb instead.
I did try, I guess I'll try some more. I had trouble with gdb and symbols as all
the relocations seemed to screw up function locations and it had difficulty realizing
where exactly it was. Maybe I just didn't try hard enough.
>
> Do you mean these patches? Those are all I have.
>
> 1999-06-25 Andreas Schwab <[EMAIL PROTECTED]>
>
> * elf/dl-deps.c (_dl_map_object_deps): When looking for the next
>
> 1999-06-17 Andreas Jaeger <[EMAIL PROTECTED]>
>
> * elf/dl-load.c (_dl_init_paths): Add one more element to aelem
> Andreas
> --
> Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
> for pgp-key finger [EMAIL PROTECTED]
Yeah, those are the patches I applied - didn't help. Ok, I'll try to narrow this
down further before bothering you again. If anyone else wants to give it a shot please
do - I saw plenty of posts complaining about glibc 2.x and runsocks in other groups,
it's about time we get it fixed.
Thanks,
Roman
PS I'm cc-ing this to you as my newsserver sometimes loses posts.
==============F2BCB5551F721926F8291184
Content-Type: text/x-vcard; charset=us-ascii;
name="roman.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roman Sulzhyk
Content-Disposition: attachment;
filename="roman.vcf"
begin:vcard
n:Sulzhyk;Roman
tel;work:(914) 448 7477
x-mozilla-html:TRUE
org:Prodigy Communications Inc
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Software Developer
x-mozilla-cpt:;21024
fn:Roman Sulzhyk
end:vcard
==============F2BCB5551F721926F8291184==
------------------------------
From: [EMAIL PROTECTED] (Gopal Santhanam)
Crossposted-To: comp.os.linux.misc
Subject: Where to find IOSTAT and SAR kernel patch?
Date: 29 Jun 1999 23:01:44 GMT
Hi,
The subject says it all. I'm looking for iostat and the SAR kernel
patch for Linux. I've only see reference to these two at the _Linux
Performance Tuning_ website, http://www.nl.linux.org/linuxperf/.
Any help would be appreciated.
Thanks in advance,
Gopal
------------------------------
From: [EMAIL PROTECTED] (Victor Wagner)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: 29 Jun 1999 23:56:44 +0400
Tristan Wibberley <[EMAIL PROTECTED]> wrote:
: Cameron Hutchison wrote:
:>
:> mlw <[EMAIL PROTECTED]> writes:
:>
:> >As for Audio, what the hell does a GUI have to do with audio? Yes, Linux
:> >needs a standard networked streaming audio spec, but that is not "X."
:>
:> >You may be confusing X with the Window manager. X is conceptually a
:> >display driver/interface.
:>
:> It is/should be more than that. It's the user interface.
: No, it's the windowing system *part* of the whole user interface, which
: is far bigger and much more complicated.
I agree with this. There is no reason to integrate networked sound
subsystem into X. Of course, existing implementation (NAS, see
ftp://ftp.ncd.com/pub/nas) have its shortcomings, but I use it every day
and found it good enough. And it doesn't require me to run X if I want
just to listen mpeg3! One of best advantages of Linux/Unix over Windows
is that if I don't like to see GUI just now, I can switch to another
virtual console and go with CLI. Or may be even turn monitor off and go
with pure sound interface, if one writes it.
: The user interface includes windowing system, toolkits, WM's, Task
: managers, sound interfaces, and much more. X is a very, very, very small
: part of that.
: Window system events and other events do need to be syncronised, so X
: needs syncronisation support, not sound support. X is so well designed,
: of course, that this can be added *easily*.
And NAS is already integrated with Xt event loop. Unfortunately no one
now uses Xt-based toolkits - Tk, Xview, Xforms, Gtk, Qt and so on.
And in case if you use sound as most of silly GUI use it - just play
prerecorded clips on some events, not to carry _information_ via sound,
there is concept of server-side sound cache, which makes network
traffic negligible and syncronization problem nearly not existsent.
Of course, these problems arise when you want to watch sound-enabled
movie. In this case sound carries _information_. (unless it is
advertisment, of course).
--
========================================================
Victor Wagner @ home = [EMAIL PROTECTED]
I don't answer questions by private E-Mail from this address.
------------------------------
From: herman <[EMAIL PROTECTED]>
Subject: Sleeping or not?
Date: 29 Jun 1999 13:32:48 PDT
Hi,
I'm working on a driver and need to know at the Interrrup Service
Routine (ISR) if the "read" call is sleeping or not.
The user program calls "read" and if no data is available, it initiates
bus master xfer and blocks till some data is available.
When the xfer is complete, a hardware interrupt is triggered. The
interrupt service routine (ISR) saves the filled buffer pointer and
count, wakes up the blocked "read", and initiates another bus master
xfer to a new buffer (circular buffer with multiple pages). If "read"
is not blocked, then the ISR should not initiate another xfer, but
should terminate the collection sequence.
The ISR routine wants to know if "read" is blocked and sleeping, waiting
for more data. How can ISR tell this condition? Would
current->blocked work at the ISR level? Should I just use a variable
like a flag?
TIA
Herman Watson
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking,comp.lang.c++
Subject: Re: Why not C++
Date: 29 Jun 1999 16:17:26 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (NF Stevens)
writes:
>[EMAIL PROTECTED] (Nathan Myers) wrote:
>
>[snip]
>
>>If you don't know C++ templates, you don't know C++ at all. It is
>>templates, for example, that make it possible to write a C++ library
>>that does matrix operations as efficiently as specially-optimizing
>>Fortran on machines specifically designed to run Fortran well. Unlike
>>Fortran, though, C++ templates are not tuned specificially for matrix
>>math, so can be used to accomplish similar wonders in any area.
>
>I have to disagree with this. Templates do not in any way improve
>the efficiency of generated code. They are no faster (and no
>slower) than the equivalent hand written code. Templates only
>improve the efficiency of the programmer since only one (templated)
>version has to be coded rather than individual versions for each
>template class.
Yes and no. Yes, in that what you say can be the case.
However, you are comparing things with what I'll call different
granularity levels. For instance, there is a dimension to templates
that I'll say is analogous to say the pointer alias rules in C,
which allow specific optimizations to occur. Knowing that some
templates came from the same generic descriptions DOES allow
certain shall we say global analysis to occur that either would
not be otherwise or at least very hard otherwise. This is distinctly
an efficiency issue. Also, I'll be hard pressed to have ever seen
the kinds of matrix ops Nathan is mentioning able to be done in C.
If Linus want to talk about theory and practice, well, this one's
practice for C :)
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
