Linux-Development-Sys Digest #901, Volume #6 Mon, 28 Jun 99 06:13:49 EDT
Contents:
Re: NT kernel guy playing with Linux (Kai Henningsen)
Re: memcpy from mmap'ed buffers (Nitin Malik)
Re: Why not C++ (John E. Davis)
Re: Why not C++ (Paul Jackson)
Re: Why not C++ ("Thomas Stuefe")
Re: linux parallel port program (Uwe Bonnes)
Re: Why not C++ (Nathan Myers)
Re: Why not C++ (Nathan Myers)
Re: Why not C++ (Bruce Hoult)
Re: Why not C++ ("Tom Leete")
[root=?](initrd) (jauming)
Re: Why not C++ (Johan Kullstam)
help me please, URGENT ("Thierry BUCCO")
Re: Why not C++ (Johan Kullstam)
Re: Why we are still holding on to X Windows (Marcus Sundberg)
----------------------------------------------------------------------------
Date: 27 Jun 1999 13:39:00 +0200
From: [EMAIL PROTECTED] (Kai Henningsen)
Subject: Re: NT kernel guy playing with Linux
[EMAIL PROTECTED] (John Hughes) wrote on 25.06.99 in
<[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] (Philipp Thomas) writes:
>
> > On Wed, 23 Jun 1999 18:18:15 +0200, Mario Klebsch
> > <[EMAIL PROTECTED]> wrote:
> >
> > >Unfortunately, they never were popular (probably because of their
> > >origin at AT&T), so Linux did not reinvent this wheel.
> >
> > It's not because STREAMS originated at AT&T, but because of
> > performance. As anybody who has worked with streams will tell you,
> > they suck performance wise. Specially the streams based TCP/IP stacks.
>
> Nope. Untrue. FUD.
Well, it certainly is the common perception.
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery ([EMAIL PROTECTED])
------------------------------
Date: Mon, 28 Jun 1999 00:03:03 -0400
From: Nitin Malik <[EMAIL PROTECTED]>
Subject: Re: memcpy from mmap'ed buffers
Arun Sharma wrote:
> (a) How are you measuring time ? rdtsc is a good way to do it on ix86.
yup I am using rdtsc (and do_gettimeofday). btw, I never got around to print a
unsigned long long in the kernel... I tried the "%llu", "%Lu" and "%qu" format
specifiers but they didn't give me the correct result.
> (b) If you're seeing abnormal numbers, they could be attributed to:
>
> (a) Cachability of the memory range in question.
>
then why do the original timings don't reflect the same overhead?
> (b) Page fault handling overhead - you may be doing a lot more
> user->kernel transitions.
> I'd suggest:
>
> - varying the size of the buffers to see the variation in numbers
gives the same overhead.... Moreover I used the assembly memcpy code from the
kernel, for small data sizes I got better results but as the size got bigger,
the timings got screwed. any reason why this shud occur?
> - watching the page fault stats in /proc/stat
>
didn't change...
> - profile the kernel (man readprofile)
I have been trying to get the damn thing working for ages... it works fine for
all routines except the TCP/IP functions. Can u please tell me if there is
something I am missing.... I followed the man pages...
--
nitin
------------------------------
From: [EMAIL PROTECTED] (John E. Davis)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking,comp.lang.c++
Subject: Re: Why not C++
Date: 28 Jun 1999 04:22:09 GMT
Reply-To: [EMAIL PROTECTED]
On 27 Jun 1999 23:17:45 -0400, Greg Comeau <[EMAIL PROTECTED]>
wrote:
>>>structs as type names, references, cleaned-up casting, and default
>>>arguments make C++ better than C.
[...]
>>supports an `inline' keyword. As far as structs as type names go, why
>>not use a typedef? That is,
[...]
>This doesn't follow and so seems flawed. Ok, for whatever reason, you
>don't like or understand or need (whichever applies) C++. However,
>with your reasoning, doing the typedef would not be compelling either.
>So why wouldn't you just use struct and not typedef? For that matter,
>why not just code in binary?
The original poster said that, among other things, "structs as type
names....make C++ better than C". I interpreted his statement as
meaning that, e.g.,
Vector *x;
is better than
struct Vector *x;
I merely pointed out that he can use a `typedef' to achieve this.
--John
------------------------------
From: [EMAIL PROTECTED] (Paul Jackson)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 28 Jun 1999 05:14:38 GMT
Nathan Myers wrote:
|> [Those saying] it's slower than (e.g.) C are just spreading FUD.
Paul Jackson <[EMAIL PROTECTED]> wrote:
|> >Put it this way -- if I could actually try ten
|> >different teams ... using different languages to implement
|> >a real world (multi-year, requirements changing
|> >for the life of the project, ...) app, right
|> >now I'd bet that Python team (a delightful language
|> >that I just learning) would produce the fastest
|> >working app ...
Nathan Myers wrote:
|> Odd choice of example; Python is written in C++.
|>
|> I will assert that my team using Python with C++ modules would
|> produce the fastest result, soonest.
Well, first of all, what language a language's compiler or
interpreter is written in doesn't really matter here, does it?
Also, Python is (currently, as of 1.5.2) written in C (as
someone else just noted as well). Though my recommendation,
when this topic came up on the python news group, was for
Guido to write Python 2.0 in C++, not C. Not because it was
faster (or slower), but because it would provide someone of
Guido's skill additional ways to express the structure of his
code.
But actually I think we are in agreement on one thing:
... the team using Python with C++ modules ...
would likely 'win'.
--
But really, I think you missed my primary point:
That the speed of a given modest well-defined app produced
by a sufficiently skilled developer is not necessarily the
best thing to compare, when choosing a language to produce
a 'real-world' (messy to the max ') app using a mixed bag
collection of developers.
Sometimes, a language that is 'safer' or 'simpler' or 'easier
to grasp intellectually' will produce better (faster,
quicker, easier to adapt, less buggy, ...) results, in
the hands of the 'average' programmer, or for sufficiently
messy apps, than will the super-power-buzzsaw-adaptable tool
(C++, I mean). Even though, in the hands of the sufficiently
skilled (clearly including Nathan), for sufficiently well
defined apps, C++ would more likely be the superior tool.
In short, attempts to consider the 'speed of a language' outside
the context of the app and the programmer (and others would
add - the compiler maturity), are in themselves a form of FUD.
--
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson ([EMAIL PROTECTED]; [EMAIL PROTECTED]) 3x1373 http://sam.engr.sgi.com/pj
------------------------------
From: "Thomas Stuefe" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking,comp.lang.c++
Subject: Re: Why not C++
Date: Mon, 28 Jun 1999 07:55:12 +0200
>> In my opinion, the only thing that C++ has over C is
>>better support for data encapsulation via classes and, possibly,
>>exception handling.
Only is good.
------------------------------
From: Uwe Bonnes <[EMAIL PROTECTED]>
Subject: Re: linux parallel port program
Date: 27 Jun 1999 18:53:14 GMT
Ho Lee <[EMAIL PROTECTED]> wrote:
: Hello,
: I am new to this usernet and I am looking for help from someone. I hope
: someone can help me out.
: I am writing a program that allows the user to read an 8-bit input from
: and write an 8-bit output to the parallel port.
: I found in a driver function in /usr/src/linux/drivers/char/lp.c
: static int lp_write(struct inode * inode, struct file * file, const
: char * buf, int count)
: and I think it deals with writing to the parallel port. So is this
: function the one I need?
: Another thing is that I couldn't find the read function for the parallel
: port. So what is the best way and easiest way that I can write the
: program to allow the user to read from the parallel port? Is there any
: places that I can find such read function? Or I have to write the
: driver function myself and compile it to the kernel?
: I don't know much about device driver programming and I really need
: help.
: Thanks for your attention.
Look for ppuser on
http://www.torque.net/parport/
Bye
--
Uwe Bonnes [EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
========= Tel. 06151 162516 ======== Fax. 06151 164321 ==========
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 22:31:14 -0700
[EMAIL PROTECTED] wrote in message ...
>In comp.os.linux.development.system Nathan Myers
>
>: Enough generalities. Take for example Egcs. C and C++, same code
>: generator, same optimizer. The last time you tried g++ was years
>: and years ago. It's time to look again.
>
>Using the latest egcs (from CVS) to compile a C program, with options
>'-fno-exceptions -fno-rtti -O2', the C assembler output is still
>smaller (in terms of # of instructions, not symbol length) while
>producing the same results.
Unsupported assertion noted (again).
What source code?
How _much_ smaller (if any)?
How _much_ faster (if any)?
Without proof, this is just more FUD.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 23:13:33 -0700
Paul Jackson <[EMAIL PROTECTED]> wrote:
>Nathan Myers wrote:
>|> [Those saying C++ is] slower than (e.g.) C are just spreading FUD.
>
>But really, I think you missed my primary point: ...
>In short, attempts to consider the 'speed of a language' outside
>the context of the app and the programmer (and others would
>add - the compiler maturity), are in themselves a form of FUD.
FUD has been, is, and will be.
Yet, competence is still a far scarcer commodity than CPU cycles.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Mon, 28 Jun 1999 18:58:13 +1200
In article <[EMAIL PROTECTED]>, Johan Kullstam
<[EMAIL PROTECTED]> wrote:
> > Does CMUCL have a way of declaring that a certain class will never have
> > subclasses added? Does CMUCL have a way of declaring that a certain
> > generic function will never have methods added or removed?
>
> generic functions as part of CLOS cannot guarentee that new methods
> will not be added. however, if at calling you are passing variables
> with declared types, then the specific method can be deduced at
> compile-time.
That's true if:
- the variables can not be of a subclass of the declared class, AND
- the method found at compile time matches the declared types of the
arguments *exactly* (so that no more specific method added at
run time could be more applicable), AND
- the method found at runtime can not be removed and replaced in the
generic function.
It doesn't sound as if CLOS can guarantee any of these, excep for types
which are not objects and functions which are not generic.
> > If it doens't then how can it optomise this call? Some other bit of code
> > may change what "+" means at runtime.
>
> in this instance, + isn't a generic and cannot be overloaded.
> overloading isn't such a big deal since many times a function like +
> is passed as an arg. for example if you have a mat:+ to add matrices,
'+' isn't a generic? So what happens when you call '+' with arguments
whose types are not known at compile time?
-- Bruce
------------------------------
From: "Tom Leete" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Mon, 28 Jun 1999 00:10:52 -0400
[EMAIL PROTECTED] wrote in message ...
>In comp.os.linux.development.system Nathan Myers
<[EMAIL PROTECTED]> wrote:
>: Linus Torvalds <[EMAIL PROTECTED]> wrote:
>:>Bruce Hoult <[EMAIL PROTECTED]> wrote:
>:>
>:>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.
>:>
>:>Sometimes theory matters. Sometimes it doesn't. The world is not as
>:>simple as you make it out to be.
>
>: Enough generalities. Take for example Egcs. C and C++, same code
>: generator, same optimizer. The last time you tried g++ was years
>: and years ago. It's time to look again.
>
>
>Using the latest egcs (from CVS) to compile a C program, with options
>'-fno-exceptions -fno-rtti -O2', the C assembler output is still
>smaller (in terms of # of instructions, not symbol length) while
>producing the same results.
>
You're lobotomizing the compiler before it starts. The optimizer uses
rtti info to do its job. Explicit use of rtti in a C++ program is
usually pretty bad style (templates solve most of those kinds of
problems better), but the rtti markers are used to give hints to the
optimizer. If you want to test g++ as an optimizing compiler, don't turn
on all those non-C++ language restrictions.
I don't know what the result of a better test will be, but there's
something of the Mindcraft Method of Testing(tm) in switching off rtti.
I suspect that g++ will still give bigger and slower code. The egcs
project has been mainly working on meeting the v2 standard, and the
optimizer seems a little anemic. I imagine that will change someday.
Regards,
Tom
------------------------------
From: jauming <[EMAIL PROTECTED]>
Subject: [root=?](initrd)
Date: Mon, 28 Jun 1999 07:51:34 GMT
which device name should i use for "root=" (/dev/ram"?)
if im using "initrd"?
thx in advanced!:)
btw, is it necessary to do device_setup() before mount_root()?
--
--
regards
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 28 Jun 1999 04:48:25 -0400
[EMAIL PROTECTED] (Bruce Hoult) writes:
> In article <[EMAIL PROTECTED]>, Johan Kullstam
> <[EMAIL PROTECTED]> wrote:
> > ???? writes:
> > > If it doens't then how can it optomise this call? Some other bit of code
> > > may change what "+" means at runtime.
> >
> > in this instance, + isn't a generic and cannot be overloaded.
> > overloading isn't such a big deal since many times a function like +
> > is passed as an arg. for example if you have a mat:+ to add matrices,
>
> '+' isn't a generic? So what happens when you call '+' with arguments
> whose types are not known at compile time?
the same thing as when you call any ordinary function. however if you
do know the args and they are specialized enough, it can compile it
down to machine code.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: "Thierry BUCCO" <[EMAIL PROTECTED]>
Subject: help me please, URGENT
Date: Mon, 28 Jun 1999 10:37:27 +0200
Hi,
in the top of my program, i redirect stdout & stderr in a file, like this :
stdout_file = freopen("/root/stdout.txt","a",stdout)
stdout_file = freopen("/root/stdout.txt","a",stderr)
and i modify his buffer's size
setbuf(stdout_file, NULL);
In fact i want to retrieve all stdout and stderr information, and put then
into a file. The problem is : the file is created, but there's nothing into.
I must stop my program to see information (empty buffer ?)
How can i resolve my problem ?
Thanks in advance.
Thierry - FRANCE
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 28 Jun 1999 04:53:20 -0400
"Tom Leete" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote in message ...
> >In comp.os.linux.development.system Nathan Myers
> <[EMAIL PROTECTED]> wrote:
> >: Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >:>Bruce Hoult <[EMAIL PROTECTED]> wrote:
> >:>
> >:>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.
> >:>
> >:>Sometimes theory matters. Sometimes it doesn't. The world is not as
> >:>simple as you make it out to be.
> >
> >: Enough generalities. Take for example Egcs. C and C++, same code
> >: generator, same optimizer. The last time you tried g++ was years
> >: and years ago. It's time to look again.
> >
> >
> >Using the latest egcs (from CVS) to compile a C program, with options
> >'-fno-exceptions -fno-rtti -O2', the C assembler output is still
> >smaller (in terms of # of instructions, not symbol length) while
> >producing the same results.
> >
>
> You're lobotomizing the compiler before it starts. The optimizer uses
> rtti info to do its job. Explicit use of rtti in a C++ program is
> usually pretty bad style (templates solve most of those kinds of
> problems better), but the rtti markers are used to give hints to the
> optimizer. If you want to test g++ as an optimizing compiler, don't turn
> on all those non-C++ language restrictions.
why would turning off rtti -- *run time* type information -- have
anything to do with *compile time* optimization?
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: Marcus Sundberg <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Mon, 28 Jun 1999 11:03:57 +0200
Neal Tucker wrote:
>
> Marcus Sundberg <[EMAIL PROTECTED]> wrote:
> >
> >There exists no software named "X Windows".
>
> Oh yeah, it's "The X Windowing System." Just like there's no
> software named "Win95" -- it's "Windows 95". Just like there's
> no such thing as "Cheez-its" -- they're "Cheez-it snack crackers".
> (i.e. who cares ... people call it what is convenient, and as
> long as it's not hindering discussion, it's counterproductive
> to bitch and moan about it)
People say/write "Win95" because it's shorter than "Windows 95".
"X Windows" is longer than both "X" and "X11", which are correct
terms, so there is no reason to use the incorrect term.
> It should not be up to the application to figure out which
> set of speakers is associated with which keyboard.
No it shouldn't, but it shouldn't be up to the windowing system either.
It should be up to the user, by setting an environment variable or some
such. Just because I want sound when I play Quake doesn't mean I want
every braindead application playing sounds as soon as I touch a button
in it.
//Marcus
--
===============================+====================================
Marcus Sundberg | http://www.stacken.kth.se/~mackan/
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
------------------------------
** 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
******************************
