Re: Why C Is Not My Favourite Programming Language
evolnet...@gmail.com
many C programs written by presumably experienced coders and yet so few
in programs written in *any other language*?
Joona I Palaste
on comp.lang.c:
> In that case, why is it that there are so many buffer overflows in so
> many C programs written by presumably experienced coders and yet so few
> in programs written in *any other language*?
I find it hard to believe there are more buffer overflows in C programs
than there are in assembly programs. Unless you don't count assembly as
a language.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"It was, er, quite bookish."
- Horace Boothroyd
evolnet...@gmail.com
don't overuse assembly language as they do C.
CBFalconer
For the same reasons that most automobile accidents have a
teen-ager at the heart of it. Teen-ager implies novice. Today
that teenager gets a copy of "Dummies Learn C in 28 minutes", or
some other BullSchildt, together with a whiz bang IDE, and
laboriously create a "Hello World" that occupies 0.25 megabytes
[1]. They now cackle fatuosly and go to work for General Crap
Software. Some of them in this very newsgroup even claim to work
for NASA and jpl.
[1] While in the days of CP/M a "Hello World" could be about 25
bytes. It need not be appreciably larger today.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Michael Mair
> evolnet...@gmail.com wrote:
>
>>In that case, why is it that there are so many buffer overflows in
>>so many C programs written by presumably experienced coders and yet
>>so few in programs written in *any other language*?
>
>
> For the same reasons that most automobile accidents have a
> teen-ager at the heart of it. Teen-ager implies novice. Today
> that teenager gets a copy of "Dummies Learn C in 28 minutes", or
> some other BullSchildt, together with a whiz bang IDE, and
> laboriously create a "Hello World" that occupies 0.25 megabytes
> [1]. They now cackle fatuosly and go to work for General Crap
> Software. Some of them in this very newsgroup even claim to work
> for NASA and jpl.
>
> [1] While in the days of CP/M a "Hello World" could be about 25
> bytes. It need not be appreciably larger today.
Darn, I made it never below 1/2K (including standard startup and cleanup
code)...
-Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Randy Howard
evolnet...@gmail.com says...
> In that case, why is it that there are so many buffer overflows in so
> many C programs written by presumably experienced coders
There lies the flaw -- "presumably experienced".
--
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig
Steven
cleanup
> code)...
Steven
Michael Mair
> I got "hello world!" down to exactly 25 bytes. (A86 assembly)
Now that you have posted it three times, we are already at 75 B ;-)
I was talking about C, compiled without any dirty tricks (maybe a
pragma) and linked against standard startup and cleanup code.
Without that, you essentially have only to locate printf or puts
or whatever in your implementation's standard library and pass
the string to it.
This does not count IMO.
Cheers
Steven
Anyway, this is exactly why I like C and Assembly, you can make it so
efficient. Got it down to 21 bytes so far (Only 8 bytes of
instructions!)
CBFalconer
> Steven wrote:
>
>> I got "hello world!" down to exactly 25 bytes. (A86 assembly)
>
> Now that you have posted it three times, we are already at 75 B ;-)
> I was talking about C, compiled without any dirty tricks (maybe a
> pragma) and linked against standard startup and cleanup code.
> Without that, you essentially have only to locate printf or puts
> or whatever in your implementation's standard library and pass
> the string to it.
>
> This does not count IMO.
No? If your C system makes an executable file somewhere in the
25,000 to 250,000 byte range this means a bloat factor of between
1000 and 10,000 is involved. This shows why a Z80 with 64k of
memory could keep up for so long. Today the hardware is something
in that 1000 to 10,000 range faster than my 2 Mhz z80 was, and
memory is about 1000 times larger, with virtual memory about 10,000
times larger. However the bloat and tail-chasing have kept
performance in the same general ball park.
Another comparison - disk storage has gone from 400k per floppy to
40 GB per hard disk. That's a factor of 100,000, and is the reason
we don't have storage space problems. The disks are staying ahead
of the bloat.
</rant>
CBFalconer
mov dx,msg
mov al,??
int ??
mov al,??
int ??
msg db 'Hello World$'
(I have forgotten a lot - but CP/M is almost exactly the same)
Francis Glassborow
<cbfal...@yahoo.com> writes
>No? If your C system makes an executable file somewhere in the
>25,000 to 250,000 byte range this means a bloat factor of between
>1000 and 10,000 is involved.
but largely an overhead paid by any C program created by the
implementation for that environment.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
tomst...@gmail.com
CBFalconer wrote:
> Michael Mair wrote:
> > Steven wrote:
> >
> >> I got "hello world!" down to exactly 25 bytes. (A86 assembly)
> >
> > Now that you have posted it three times, we are already at 75 B ;-)
> > I was talking about C, compiled without any dirty tricks (maybe a
> > pragma) and linked against standard startup and cleanup code.
> > Without that, you essentially have only to locate printf or puts
> > or whatever in your implementation's standard library and pass
> > the string to it.
> >
> > This does not count IMO.
>
> No? If your C system makes an executable file somewhere in the
> 25,000 to 250,000 byte range this means a bloat factor of between
> 1000 and 10,000 is involved. This shows why a Z80 with 64k of
> memory could keep up for so long. Today the hardware is something
> in that 1000 to 10,000 range faster than my 2 Mhz z80 was, and
> memory is about 1000 times larger, with virtual memory about 10,000
> times larger. However the bloat and tail-chasing have kept
> performance in the same general ball park.
Um...
With or without debug symbols?
With or without relocation tables?
With or without optimizations?
With or without proper code factorization?
if you compile with "-g3 -O3 -funroll-all-loops" and bitch about
"bloat" then you got your head up your ass.
A stub empty main function on ELF-i386 with the latest GNU tools is
3.1KiB. Just the object is 729 bytes and the actual code amounts to 35
bytes. [this is with no optimizations or other flags].
The 35 bytes are
laptop ~ # ndisasm -b 32 test.bin
00000000 55 push ebp
00000001 89E5 mov ebp,esp
00000003 83EC08 sub esp,byte +0x8
00000006 83E4F0 and esp,byte -0x10
00000009 B800000000 mov eax,0x0
0000000E 83C00F add eax,byte +0xf
00000011 83C00F add eax,byte +0xf
00000014 C1E804 shr eax,0x4
00000017 C1E004 shl eax,0x4
0000001A 29C4 sub esp,eax
0000001C B800000000 mov eax,0x0
00000021 C9 leave
00000022 C3 ret
Which is a long drawn out process to make a stack frame. With -O3 and
no stack frame we get a 16 byte routine:
00000000 55 push ebp
00000001 31C0 xor eax,eax
00000003 89E5 mov ebp,esp
00000005 83EC08 sub esp,byte +0x8
00000008 83E4F0 and esp,byte -0x10
0000000B 83EC10 sub esp,byte +0x10
0000000E C9 leave
0000000F C3 ret
Which despite saying -fomit-frame-pointer still actually makes a
frame... I guess GCC can't optimize an empty function to well ;-)
My point is those images you are bitching about contain a lot more than
just code and they're not hand-tuned to a given task. Libraries have
to be fairly robust to get widespread use. So little "tricks" that
embedded developers use [and I know I used to be one] to shave a byte
here and there aren't very practical when you're writing code that a
thousand different people will call upon.
Tom
Antoine Leca
> mov dx,msg
> mov al,??
> int ??
OK so far (should be ah).
> mov al,??
> int ??
Not needed. ret does the job. The OS pushes a zero on the top of the stack,
and returning to it is a way to exit.
Yet I fail to see the point of your post.
Antoine
Michael Mair
CBFalconer wrote:
> Michael Mair wrote:
>
>>Steven wrote:
>>
>>
>>>I got "hello world!" down to exactly 25 bytes. (A86 assembly)
>>
>>Now that you have posted it three times, we are already at 75 B ;-)
>>I was talking about C, compiled without any dirty tricks (maybe a
>>pragma) and linked against standard startup and cleanup code.
>>Without that, you essentially have only to locate printf or puts
>>or whatever in your implementation's standard library and pass
>>the string to it.
>>
>>This does not count IMO.
>
>
> No? If your C system makes an executable file somewhere in the
> 25,000 to 250,000 byte range this means a bloat factor of between
> 1000 and 10,000 is involved. This shows why a Z80 with 64k of
> memory could keep up for so long. Today the hardware is something
> in that 1000 to 10,000 range faster than my 2 Mhz z80 was, and
> memory is about 1000 times larger, with virtual memory about 10,000
> times larger. However the bloat and tail-chasing have kept
> performance in the same general ball park.
>
> Another comparison - disk storage has gone from 400k per floppy to
> 40 GB per hard disk. That's a factor of 100,000, and is the reason
> we don't have storage space problems. The disks are staying ahead
> of the bloat.
>
> </rant>
Even though your rant is in and by itself fully justified, you entirely
fail to not miss my point ;-)
See Tom's post...
And yes, I have seen .25 M overhead for "Hello world!", too.
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.
lawrenc...@ugs.com
Because there are so many commonly used programs written in C and so few
(relatively speaking) written in any other language.
-Larry Jones
All girls should be shipped to Pluto--that's what I say. -- Calvin
Keith Thompson
First, you posted about 600 lines of stuff to comp.lang.c. That's not
necessarily a bad thing in itself, but as somebody else pointed out,
it appears to be essentially identical to an article posted by James A
C Joyce to Kuro5hin at
<http://www.kuro5hin.org/story/2004/2/7/144019/8872>
I see no mention of James A C Joyce's name in what you posted. Did
you plagiarize someone else's work, or are "James A C Joyce" and
"evolnet...@gmail.com" the same person, or is something else
going on? (I note that James A C Joyce has posted an e-mail address
on Kuro5hin, and it's not "evolnet...@gmail.com".)
Second, you introduced a gratuitous and unacknowledged cross-post to
comp.std.c, which did not see the original article. This is, at best,
rude.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Joona I Palaste
on comp.lang.c:
> Steven wrote:
>>
>> I *think* I deleted the other posts, my browser was acting up.
>> Anyway, this is exactly why I like C and Assembly, you can make
>> it so efficient. Got it down to 21 bytes so far (Only 8 bytes
>> of instructions!)
> mov dx,msg
> mov al,??
> int ??
> mov al,??
> int ??
> msg db 'Hello World$'
> (I have forgotten a lot - but CP/M is almost exactly the same)
$C000 LDX #$0A
$C002 LDA $C00E,X
$C005 STA $0400,X
$C008 DEX
$C009 BNE $C002
$C00B RTS
$C00C msg db "Hello World"
There you go, 22 bytes. I don't have a real Commodore 64 any more to
try it out, but it should print "Hello World" at the top left corner
of the screen. Damn, someone beat me with 1 byte, and with a more
complicated machine, no less. =)
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"We sorcerers don't like to eat our words, so to say."
- Sparrowhawk
Joona I Palaste
on comp.lang.c:
> $C000 LDX #$0A
> $C002 LDA $C00E,X
This should be $C002 LDA $C00C,X of course.
> $C005 STA $0400,X
> $C008 DEX
> $C009 BNE $C002
> $C00B RTS
> $C00C msg db "Hello World"
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"I wish someone we knew would die so we could leave them flowers."
- A 6-year-old girl, upon seeing flowers in a cemetery
Bas Wassink
> Joona I Palaste <pal...@cc.helsinki.fi> scribbled the following
> on comp.lang.c:
>> $C000 LDX #$0A
>> $C002 LDA $C00E,X
>
> This should be $C002 LDA $C00C,X of course.
>
>> $C005 STA $0400,X
>> $C008 DEX
>> $C009 BNE $C002
>> $C00B RTS
>> $C00C msg db "Hello World"
You should change BNE to BPL, otherwise you'll print "ello World" to $0401.
Lawrence Kirby
> Joona I Palaste <pal...@cc.helsinki.fi> scribbled the following
> on comp.lang.c:
>> $C000 LDX #$0A
>> $C002 LDA $C00E,X
>
> This should be $C002 LDA $C00C,X of course.
>
>> $C005 STA $0400,X
>> $C008 DEX
>> $C009 BNE $C002
Shouldn't that be BPL?
>> $C00B RTS
>> $C00C msg db "Hello World"
Lawrence
Mabden
news:cu5mri$rc8$1...@oravannahka.helsinki.fi...
> evolnet...@gmail.com scribbled the following
> on comp.lang.c:
> > In that case, why is it that there are so many buffer overflows in
so
> > many C programs written by presumably experienced coders and yet so
few
> > in programs written in *any other language*?
>
> I find it hard to believe there are more buffer overflows in C
programs
> than there are in assembly programs. Unless you don't count assembly
as
> a language.
My axiom:
C is a Master's Language. Simple, Elegant, Powerful. Like a handgun. In
the right hands, it executes perfectly. In the wrong hands, it simply
executes.
My opinion:
The idea of why C bugs may be seen more often than "other" languages, is
simple. Everything you use is written in C. Your Perl translator was
written in C, as was your Visual Basic compiler. Whatever you think is
"safe" probably has a lot of C code in it. Certainly your C++ compiler
does (also, probably mostly straight C / ASM).
--
Mabden
Nicolas Pavlidis
> "Joona I Palaste" <pal...@cc.helsinki.fi> wrote in message
> news:cu5mri$rc8$1...@oravannahka.helsinki.fi...
> > evolnet...@gmail.com scribbled the following
> > on comp.lang.c:
> > > In that case, why is it that there are so many buffer overflows in
> so
> > > many C programs written by presumably experienced coders and yet so
> few
> > > in programs written in *any other language*?
> >
> > I find it hard to believe there are more buffer overflows in C
> programs
> > than there are in assembly programs. Unless you don't count assembly
> as
> > a language.
>
> My axiom:
> C is a Master's Language. Simple, Elegant, Powerful. Like a handgun. In
> the right hands, it executes perfectly. In the wrong hands, it simply
> executes.
My Problem with C is the following:
If you want to write robust, extedible and safe code, the code gets a
bit unreadable very fast. This problem is shared by all procedual
languages, allthough C has more conzepts to write such code than other
languages of this kind.
> My opinion:
> The idea of why C bugs may be seen more often than "other" languages, is
> simple. Everything you use is written in C. Your Perl translator was
> written in C, as was your Visual Basic compiler. Whatever you think is
> "safe" probably has a lot of C code in it. Certainly your C++ compiler
> does (also, probably mostly straight C / ASM).
Thats true, but it is often better to use other languages to get the
result, as using C, because of the reason I said before.
Kind regards,
Nicolas
--
| Nicolas Pavlidis | Elvis Presly: |\ |__ |
| Student of SE & KM | "Into the goto" | \|__| |
| pav...@sbox.tugraz.at | ICQ #320057056 | |
|-------------------University of Technology, Graz----------------|
Chris Croughton
<pav...@sbox.tugraz.at> wrote:
> My Problem with C is the following:
> If you want to write robust, extedible and safe code, the code gets a
> bit unreadable very fast.
That better describes Perl. Well, apart from the bits about robust and
safe code...
> This problem is shared by all procedual
> languages, allthough C has more conzepts to write such code than other
> languages of this kind.
C is one of few languages which even has a standard. And it's one of
few modern languages which even has a compiler (Perl, Python and Java
are interpreted, which is why they are 'safe' in some fashion because
the interpreter can check for things like invalid accesses -- at the
cost of speed and complexity elsewhere). They can also be more
'extendable' that way (FORTH is the ultimate extendable language), but
that isn't always an advantage (I've heard FORTH -- and Perl --
programmers praising the language because they can "write things no one
else can understand" by using their own extensions, as though that is a
good thing).
>> My opinion:
>> The idea of why C bugs may be seen more often than "other" languages, is
>> simple. Everything you use is written in C. Your Perl translator was
>> written in C, as was your Visual Basic compiler. Whatever you think is
>> "safe" probably has a lot of C code in it. Certainly your C++ compiler
>> does (also, probably mostly straight C / ASM).
>
> Thats true, but it is often better to use other languages to get the
> result, as using C, because of the reason I said before.
No, it is sometime better to use other languages for specific tasks
because those languages are better at those specific tasks. I wouldn't
write a web CGI program in C, I'd use PHP because it's designed for
that; if I wanted heavy number crunching I'd still use Fortran (or
assembler for the specific platform); if I want string and shell
handling I use AWK or Perl; etc.
No language is perfect. No editor is perfect, nor is any operating
system or CPU. They are all compromises and they are designed for and
best at certain tasks.
A good programmer should know many different programming languages, and
know the strengths and weaknesses of them for the programs required. It
is rare that a programmer gets a completely free hand (often the choice
of language is up to management) but there are often opportunities for a
programmer to choose the best for a specific job (at my work we have
some using Perl, some using Java, some using C and some using C++, for
different jobs; I use C for portable code, Awk and C++ (and Unix/POSIX
utilities) for local utilities and processing).
Chris C
David R Tribble
>> This problem is shared by all procedual
>> languages, allthough C has more conzepts to write such code than
other
>> languages of this kind.
Chris Croughton wrote:
> C is one of few languages which even has a standard. And it's one of
> few modern languages which even has a compiler (Perl, Python and Java
> are interpreted, which is why they are 'safe' in some fashion because
> the interpreter can check for things like invalid accesses -- at the
> cost of speed and complexity elsewhere).
That's a common misconception. Perl and Java (I don't know about
Python) are compiled languages, using a true grammatic parser and code
generator just like any C/C++ compiler. The only difference is that
the code generated by their parsers is not machine code, but some kind
of intermediate low-level p-code. (For Java it's JVM bytecode, for
Perl it's probably an abstract parse tree.) The resulting code is
typically executed on a code simulator, which allows every instruction
to be checked for safety as it's being executed.
But that being said, there also exist Java compilers that generate
native machine code for some platforms (ix86 in particular). They
just don't seem to be very popular.
There are studies that show that Java code, when executed in the right
environment (e.g., a server JVM with just-in-time compilation
enabled), can match the performance of compiled C++ code. So it's not
true that interpreted languages are necessarily slower than
native-compiled languages. Keep in mind that for many applications,
I/O speed is the bottleneck, so a 50% increase in the speed of
memory-bound code probably won't be noticed by the end user.
> They can also be more 'extendable' that way (FORTH is the ultimate
> extendable language), but that isn't always an advantage (I've
> heard FORTH -- and Perl -- programmers praising the language because
> they can "write things no one else can understand" by using their
> own extensions, as though that is a good thing).
Any sufficiently advanced programmer (or, for the opposite reasons,
any insufficiently advanced programmer) can write code that no one
else can understand, in any language. Some languages make this easier
to do than others, but none of them make it impossible.
> No language is perfect. No editor is perfect, nor is any operating
> system or CPU. They are all compromises and they are designed for
> and best at certain tasks.
Well, at least THAT's true. Pick your poison.
-drt
Chris Croughton
<da...@tribble.com> wrote:
> Nicolas Pavlidis wrote:
>>> This problem is shared by all procedual
>>> languages, allthough C has more conzepts to write such code than
>>> other
>>> languages of this kind.
>
> Chris Croughton wrote:
>> C is one of few languages which even has a standard. And it's one of
>> few modern languages which even has a compiler (Perl, Python and Java
>> are interpreted, which is why they are 'safe' in some fashion because
>> the interpreter can check for things like invalid accesses -- at the
>> cost of speed and complexity elsewhere).
>
> That's a common misconception. Perl and Java (I don't know about
> Python) are compiled languages, using a true grammatic parser and code
> generator just like any C/C++ compiler.
That's irrelevant (the same is true for many Pascal and Basic
compilers). The point is that what makes them 'safe' is the sandboxing
(to use the Java term) which is generally done by producing 'executable'
code which runs on an interpreter (or virtual machine).
> The only difference is that
> the code generated by their parsers is not machine code, but some kind
> of intermediate low-level p-code. (For Java it's JVM bytecode, for
> Perl it's probably an abstract parse tree.) The resulting code is
> typically executed on a code simulator, which allows every instruction
> to be checked for safety as it's being executed.
Yup, and that is both what makes them 'safe' and what makes them
typically slow.
> But that being said, there also exist Java compilers that generate
> native machine code for some platforms (ix86 in particular). They
> just don't seem to be very popular.
Well, part of the point of Java is "write once run anywhere", and
producing processor-specific code negates that.
> There are studies that show that Java code, when executed in the right
> environment (e.g., a server JVM with just-in-time compilation
> enabled), can match the performance of compiled C++ code. So it's not
> true that interpreted languages are necessarily slower than
> native-compiled languages. Keep in mind that for many applications,
> I/O speed is the bottleneck, so a 50% increase in the speed of
> memory-bound code probably won't be noticed by the end user.
Hmm, ever tried to use Sun's Java system configuration utilities? This
is code written by the authors of the language, and their own JVM on
their own systems, and they are painful to use. Many seconds just to
display a list of options.
OK, it doesn't have to be like that, but the GNU autoconf scropts (also
interpreted in bash) are far faster...
>> They can also be more 'extendable' that way (FORTH is the ultimate
>> extendable language), but that isn't always an advantage (I've
>> heard FORTH -- and Perl -- programmers praising the language because
>> they can "write things no one else can understand" by using their
>> own extensions, as though that is a good thing).
>
> Any sufficiently advanced programmer (or, for the opposite reasons,
> any insufficiently advanced programmer) can write code that no one
> else can understand, in any language. Some languages make this easier
> to do than others, but none of them make it impossible.
Yup. In some ways FORTRAN 77 maked it harder to obfuscate, because of
the rigid line structure (at most one statement per line, continuation
and comment lines clearly marked, no macros...). Of course, it also
made it harder to write very readable programs (no block control
structures, implicit declaration of variables, limited name length...).
>> No language is perfect. No editor is perfect, nor is any operating
>> system or CPU. They are all compromises and they are designed for
>> and best at certain tasks.
>
> Well, at least THAT's true. Pick your poison.
Yup. And as I said elsewhere, I do (C, C++, Fortran, Ada, Perl, Awk,
Bash, assembler...) depending on what I need. Many times I don't need
portability, I just need the job done for a specific system and at the
time...
Chris C
Lawrence Kirby
>> The only difference is that
>> the code generated by their parsers is not machine code, but some kind
>> of intermediate low-level p-code. (For Java it's JVM bytecode, for
>> Perl it's probably an abstract parse tree.) The resulting code is
>> typically executed on a code simulator, which allows every instruction
>> to be checked for safety as it's being executed.
But typical Java runtimes can compile that into machine code before
executing it. They can even compile it into machine code with knowledge of
the specific processor it will be running on, which could result in faster
code than a typical C compiler.
> Yup, and that is both what makes them 'safe' and what makes them
> typically slow.
I don't think so. There is a start up cost for the JIT process and there
is an overhead for the safety checking but nowhere near enough to explain
the sort of slow performance you can get from Java. The whole Java
programming approach encourages excessive memory allocations, data copying
and conversions. It makes it easy to do all this stuff without thinking of
the overheads involved, or even being aware that they are there.
>> But that being said, there also exist Java compilers that generate
>> native machine code for some platforms (ix86 in particular). They
>> just don't seem to be very popular.
>
> Well, part of the point of Java is "write once run anywhere", and
> producing processor-specific code negates that.
>
>> There are studies that show that Java code, when executed in the right
>> environment (e.g., a server JVM with just-in-time compilation
>> enabled), can match the performance of compiled C++ code. So it's not
>> true that interpreted languages are necessarily slower than
>> native-compiled languages.
It is more the difference netween a "high level" and "low level" approach.
It is wrong to call Java an interpreted language, at least for current
implementations.
>> Keep in mind that for many applications,
>> I/O speed is the bottleneck, so a 50% increase in the speed of
>> memory-bound code probably won't be noticed by the end user.
That is sometimes the case, but there are many applications where that is
not true.
Lawrence
Chris Croughton
<lkn...@netactive.co.uk> wrote:
> On Tue, 15 Feb 2005 11:40:44 +0000, Chris Croughton wrote:
>
>>> The only difference is that
>>> the code generated by their parsers is not machine code, but some kind
>>> of intermediate low-level p-code. (For Java it's JVM bytecode, for
>>> Perl it's probably an abstract parse tree.) The resulting code is
>>> typically executed on a code simulator, which allows every instruction
>>> to be checked for safety as it's being executed.
>
> But typical Java runtimes can compile that into machine code before
> executing it. They can even compile it into machine code with knowledge of
> the specific processor it will be running on, which could result in faster
> code than a typical C compiler.
I've seen compilers for BASIC as well, but it is still typically
interpreted. I don't know what Sun's JVM does exceptthat it's
ridiculously slow even when there is not much happening (displaying a
list of options on a text console!).
>> Yup, and that is both what makes them 'safe' and what makes them
>> typically slow.
>
> I don't think so. There is a start up cost for the JIT process and there
> is an overhead for the safety checking but nowhere near enough to explain
> the sort of slow performance you can get from Java. The whole Java
> programming approach encourages excessive memory allocations, data copying
> and conversions. It makes it easy to do all this stuff without thinking of
> the overheads involved, or even being aware that they are there.
That as well, certainly. And part of that can be laid at the door of
the whole OO approach (C++ has the same problem).
> It is more the difference netween a "high level" and "low level" approach.
> It is wrong to call Java an interpreted language, at least for current
> implementations.
Strictly, there are very few "interpreted languages" (even FORTH has
implementations which write 'native' code and I first used a BASIC
compiler 30 years ago). There are some, like Perl, PHP and Python,
which are rarely fully compiled, some which are rarely interpreted (C,
Fortran, COBOL etc.) and some in the middle like Java.
>>> Keep in mind that for many applications,
>>> I/O speed is the bottleneck, so a 50% increase in the speed of
>>> memory-bound code probably won't be noticed by the end user.
>
> That is sometimes the case, but there are many applications where that is
> not true.
Yes, exactly. For UI code Java is not going to be a bottleneck usually
(Sun's Solaris config stuff being an exception), but for heavy number
crunching I'd go for C or Fortran (and/or with chunks of assembler for
particular optimisations). Horses for courses...
Chris C
Francis Glassborow
<ch...@keristor.net> writes
>Yes, exactly. For UI code Java is not going to be a bottleneck usually
>(Sun's Solaris config stuff being an exception), but for heavy number
>crunching I'd go for C or Fortran (and/or with chunks of assembler for
>particular optimisations). Horses for courses...
Well for heavy number crunching I would use APL as long as there was an
implementation for my hardware:-) And that is normally considered an
interpreted language.
Lawrence Kirby
> On Tue, 15 Feb 2005 16:23:02 +0000, Lawrence Kirby
> <lkn...@netactive.co.uk> wrote:
>
>> On Tue, 15 Feb 2005 11:40:44 +0000, Chris Croughton wrote:
>>
>>>> The only difference is that
>>>> the code generated by their parsers is not machine code, but some kind
>>>> of intermediate low-level p-code. (For Java it's JVM bytecode, for
>>>> Perl it's probably an abstract parse tree.) The resulting code is
>>>> typically executed on a code simulator, which allows every instruction
>>>> to be checked for safety as it's being executed.
>>
>> But typical Java runtimes can compile that into machine code before
>> executing it. They can even compile it into machine code with knowledge of
>> the specific processor it will be running on, which could result in faster
>> code than a typical C compiler.
>
> I've seen compilers for BASIC as well, but it is still typically
> interpreted.
But Java is pretty much the way of the JIT these days, perhaps less so for
embedded implementations.
> I don't know what Sun's JVM does exceptthat it's
> ridiculously slow even when there is not much happening (displaying a
> list of options on a text console!).
I don't know what is happening there either, I guess most of the time
there will be spent in the libraries rather than executing user code.
>>> Yup, and that is both what makes them 'safe' and what makes them
>>> typically slow.
>>
>> I don't think so. There is a start up cost for the JIT process and there
>> is an overhead for the safety checking but nowhere near enough to explain
>> the sort of slow performance you can get from Java. The whole Java
>> programming approach encourages excessive memory allocations, data copying
>> and conversions. It makes it easy to do all this stuff without thinking of
>> the overheads involved, or even being aware that they are there.
>
> That as well, certainly. And part of that can be laid at the door of
> the whole OO approach (C++ has the same problem).
Agreed.
>> It is more the difference netween a "high level" and "low level" approach.
>> It is wrong to call Java an interpreted language, at least for current
>> implementations.
>
> Strictly, there are very few "interpreted languages" (even FORTH has
> implementations which write 'native' code and I first used a BASIC
> compiler 30 years ago). There are some, like Perl, PHP and Python,
> which are rarely fully compiled, some which are rarely interpreted (C,
> Fortran, COBOL etc.) and some in the middle like Java.
>
>>>> Keep in mind that for many applications,
>>>> I/O speed is the bottleneck, so a 50% increase in the speed of
>>>> memory-bound code probably won't be noticed by the end user.
>>
>> That is sometimes the case, but there are many applications where that is
>> not true.
>
> Yes, exactly. For UI code Java is not going to be a bottleneck usually
> (Sun's Solaris config stuff being an exception), but for heavy number
> crunching I'd go for C or Fortran (and/or with chunks of assembler for
> particular optimisations). Horses for courses...
Number crunching is an area where Java could do well. When you're in the
middle of your matrix op, FFT, or whatever the OO stuff need not be
intrusive. The main issue there would be the form of datastructures you
use, with Java's reference mania. Java COULD be faster than C for the core
stuff with a decent JIT code generator.
Lawrence
Brian Inglis
<lkn...@netactive.co.uk> wrote:
>Number crunching is an area where Java could do well. When you're in the
>middle of your matrix op, FFT, or whatever the OO stuff need not be
>intrusive. The main issue there would be the form of datastructures you
>use, with Java's reference mania. Java COULD be faster than C for the core
>stuff with a decent JIT code generator.
Hard for a JIT code generator to do as well as a hog like gcc (at
least parts written in C++ nowadays) on optimization with effectively
no space or time constraints.
ISTM C++ and Java are suffering from severe COBOL-itis with their
continual copying, so not cooperating well with current memory-bound
processors, whereas well-written C code typically just passes a
pointer to an object around once it has been created, accessing and
modifying an existing object alrady in cache.
ISTM that fast CPUs may increase the speed difference between 3GLs and
some OO languages: the time for memory hogs is past; we need lazier
compiled languages that compute more and copy less, taking better
advantage of fast wide CPUs and caching to reduce memory pressure.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
Douglas A. Gwyn
> That as well, certainly. And part of that can be laid at the door of
> the whole OO approach (C++ has the same problem).
The main culprit is the virtual function pointer table.
However, when an object-oriented approach is justified
(as it seems to be for "widgets" etc.) then there will
be comparable overhead in any language that supports
the same kinds of operations, even for C code that does
it all manually. Better to get help from the compiler
than do it all manually!
> Yes, exactly. For UI code Java is not going to be a bottleneck usually
> (Sun's Solaris config stuff being an exception), but for heavy number
> crunching I'd go for C or Fortran (and/or with chunks of assembler for
> particular optimisations). Horses for courses...
Fortran is tailored for numerical computations, matrix
operations in particular.
C is tailored for systems implementation, e.g. device
drivers, linked data structures, etc. and serves as a
substitute for (nonportable) use of assembly language.
While C programs can be quite portable, it takes some
care, and many programmers don't bother to learn how.
For efficient development of large applications, C
requires somewhat more work to build up "support
libraries" than do some other languages, depending on
just what kind of facilities one needs. Of course,
one you have them you should be able to reuse them,
amortizing the devlopment cost across all projects.