A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows 7 » Windows 7 Forum
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

C is not a low level language



 
 
Thread Tools Rate Thread Display Modes
  #31  
Old February 25th 19, 10:52 PM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
Keith Thompson[_2_]
external usenet poster
 
Posts: 9
Default C is not a low level language

Wolf K writes:
[...]
I think human-created assembler is becoming rare. However, I have the
impression that robotics requires machine-coded assembler, translated
from whatever human-readable language was used to program the machine.


That's true of compiled languages in general, and is not specific to
robotics.

Most compiled languages are translated to assembly language
(or directly to machine language, depending on how the compiler
is designed). (Some, such as Java, are compiled to some kind of
byte code which is then interpreted, but Java can also be compiled
to assembly or machine code.)

[...]

[Followups to comp.programming, which is the only one of the
cross-posted newsgroups that seems appropriate.]

--
Keith Thompson (The_Other_Keith) http://www.ghoti.net/~kst
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Ads
  #32  
Old February 25th 19, 11:33 PM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
Bart[_7_]
external usenet poster
 
Posts: 4
Default C is not a low level language

On 25/02/2019 15:38, David Brown wrote:

There are almost no programming fields that require hand-written
assembly these days. Even if you are writing a compiler, or low-level
libraries for a compiler, you are unlikely to need more than small
sections or snippets of assembly. There are still occasions where
assembly will give you noticeably more efficient results than a
high-level language - but very, very few where the difference is big
enough to warrant using assembly. Generally, if you think assembly is
the best choice then you have picked an inappropriate processor,
inappropriate tools, or an inappropriate programmer.


The sorts of arguments can be made against using C or C++. With 90% of
the code of an application, probably it doesn't matter how efficient a
language or compiler is, because the bottlenecks are in the 10%.
  #33  
Old February 25th 19, 11:42 PM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
nospam
external usenet poster
 
Posts: 4,718
Default C is not a low level language

In article , Bart wrote:

There are almost no programming fields that require hand-written
assembly these days. Even if you are writing a compiler, or low-level
libraries for a compiler, you are unlikely to need more than small
sections or snippets of assembly. There are still occasions where
assembly will give you noticeably more efficient results than a
high-level language - but very, very few where the difference is big
enough to warrant using assembly. Generally, if you think assembly is
the best choice then you have picked an inappropriate processor,
inappropriate tools, or an inappropriate programmer.


The sorts of arguments can be made against using C or C++. With 90% of
the code of an application, probably it doesn't matter how efficient a
language or compiler is, because the bottlenecks are in the 10%.


more like 1%
  #34  
Old February 26th 19, 07:33 AM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
Scott[_11_]
external usenet poster
 
Posts: 1
Default C is not a low level language

On Mon, 25 Feb 2019 12:17:51 -0500, nospam
wrote:

In article , NY
wrote:

When I was at university, doing electronic engineering, in the early 1980s,
we did a bit of assembler programming, in 6809. Everyone was very frustrated
at the choice of CPU because those who had their own computer had either a
CP/M-based (Z80) or Commodore Pet (6502); no-one had a computer that used a
6809 that they could practice on out of hours. Of course, a few years later,
8086 and its successors (386, 486 etc) would have been fairly universal ;-)
Nowadays they'd probably also teach RISC (eg SPARC and ARM) processors.


their frustration was unfamiliarity and inability to learn new things.

the 6809 was a *very* good processor, along with its successor, the
68000 series,*far* easier to write code than the z80 and x86.


My experiences ran in the other direction. I cut teeth on the 6809,
and when I was later exposed to the 80286 it was an abrupt shift in
perspective. I never played with the 6502 or Z80, it would have
irritated me at the time, but from this distance I think it would have
been valuable experience.

it working. I forget the actual timings, but I know that the Z80 routine was
several orders of magnitude faster than the same algorithm in interpreted
BASIC and several times faster than a compiled Pascal program with the same
algorithm.


that just means the compiler wasn't any good.


No surprise with BASIC, it was always a dog in those days.

Didn't some of the Pascal systems utilize a kind of byte code running
in a virtual executive? That might do it. I never noticed Pascal being
especially slower than equivalent C, but I never did anything very
demanding with it, and I might not have been using a p-code based
system anyway. Borland used to be a hell of a compiler shop.

  #35  
Old February 26th 19, 07:51 AM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
Robert Wessel
external usenet poster
 
Posts: 2
Default C is not a low level language

On Mon, 25 Feb 2019 13:05:32 -0500, nospam
wrote:

In article , NY
wrote:

but I know that the Z80 routine was
several orders of magnitude faster than the same algorithm in interpreted
BASIC and several times faster than a compiled Pascal program with the
same
algorithm.

that just means the compiler wasn't any good.

yep, and it's *really* hard to beat a modern compiler


The compiler in question was Turbo Pascal of mid- to late-1980s vintage,
running on a Z80 under CP/M 3. I'm not sure how efficient that was.


that's not a modern compiler nor a modern processor either.

As you
say, modern compilers may well be more efficient - but they may also bloat
the code with code that was never actually called but was compiled in
nevertheless ;-)


they don't, but even if that were true, code that is not called can't
slow anything down.

I should have tried to code a more efficient sort algorithm than bubble
sort, to see how much improvement there was, but bubble is simple to
remember (*) and to code, and I was doing it as a programming exercise
rather than with a real-life application that needed the fastest sort
available.

(*) I can remember it without needing to look it up every time, and I can
visualise exactly what it's doing, whereas shell sorts start to make my
brain hurt working out what they are doing ;-)


bubble sort is very easy to write, it's just not fast.



Insertion sort is even easier to write. And it's usually twice as
fast as bubble sort.
  #36  
Old February 26th 19, 09:18 AM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
David Brown[_7_]
external usenet poster
 
Posts: 8
Default C is not a low level language

On 25/02/2019 18:49, J. P. Gilliver (John) wrote:
In message , Wolf K
writes:
On 2019-02-25 10:38, David Brown wrote:
[...]
There are almost no programming fields that require hand-written
assembly these days.Â* Even if you are writing a compiler, or low-level
libraries for a compiler, you are unlikely to need more than small
sections or snippets of assembly.Â* There are still occasions where
assembly will give you noticeably more efficient results than a
high-level language - but very, very few where the difference is big
enough to warrant using assembly.Â* Generally, if you think assembly is
the best choice then you have picked an inappropriate processor,
inappropriate tools, or an inappropriate programmer.
Â*I think it is good for programmers to have some experience of assembly,
and to have understanding of it - it helps give a better appreciation of
how things work underneath, and can lead to the programmer writing
better high-level code (especially on smaller systems).Â* But that is
different from actually writing assembly for real work.

[...]

Thanks for this,

+1. I'd agree that - IMO anyway - it helps for programmers to have had
some _experience_ of assembler, to - as you say - have a better
appreciation of how things work underneath, and write better code. But
there are now probably few places where the extra efficiency assembler
can yield justifies the extra cost of _using_ it. (_Knowing_ about it I
still think should be part of any training course that involves
programming, though.)


There are times when using some assembly code can help. It is almost
always sufficient to use inline assembly mixed with high-level code
(typically C or C++, possibly other compiled languages). You get the
benefits of assembly mainly when the processor has features that are not
easy to express in the main language - say, SIMD instructions.
Combining inline assembly with high-level language (using a compiler
that can support this well) is likely to give you more optimal code.


Yes, I still think assembler can produce more efficient code - but for
all but the simplest systems, coding it requires more brain power (which
costs money) than is justifiable in most cases: and _checking_ it is a
really stressful activity: it requires phenomenal concentration. For any
sizeable project, you need to have more than one coder working on it -
and the effort they have to put into translating the inputs and outputs
into a standard format to talk to each other arguably defeats the
efficiency gains. If they _don't_ use standard interfaces, the
_maintainability_ suffers, as any maintainer has to learn the details of
the bespoke interfaces.


Yes. Obviously anything that /could/ be written in a high level
language could also be written in assembly with at least as high
efficiency on a particular target - and there are assembly tricks that
can't be practically done with compilers. But while that is the theory,
practice is very different. If you add some reasonable conditions - the
code should be legible, maintainable, and portable within the ISA (e.g.,
it should work for any x86-64 cpu), then it is a very different matter.
The high level code will almost always run faster than assembly written
under these constraints.

This applies also for FPGA type work, too (programming in e. g. VHDL or
High-C).


Yes.

_Ideally_, the compiler - or optimiser - will remove unnecessary format
translation stages.

The two places where ultimate efficiency matter are for very long-life,
low-supply situations, such as space probes or similar situations, and
_very_ mass-produced and cheap devices. And even for both of those,
there are plenty of examples of where something went wrong - Ariane V,
that hole in MoDem/router devices from a year or two ago - though I
don't know in those particular cases whether it was in assembler or a
medium-level or high-level language where the problem occurred.


  #37  
Old February 26th 19, 09:23 AM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
David Brown[_7_]
external usenet poster
 
Posts: 8
Default C is not a low level language

On 25/02/2019 18:17, nospam wrote:
In article , David Brown
wrote:

There are almost no programming fields that require hand-written
assembly these days. Even if you are writing a compiler, or low-level
libraries for a compiler, you are unlikely to need more than small
sections or snippets of assembly. There are still occasions where
assembly will give you noticeably more efficient results than a
high-level language - but very, very few where the difference is big
enough to warrant using assembly. Generally, if you think assembly is
the best choice then you have picked an inappropriate processor,
inappropriate tools, or an inappropriate programmer.


exactly

I think it is good for programmers to have some experience of assembly,
and to have understanding of it - it helps give a better appreciation of
how things work underneath, and can lead to the programmer writing
better high-level code (especially on smaller systems). But that is
different from actually writing assembly for real work.


what matters the most are good algorithms, and knowing assembly does
not help with that.


That is often the case - but certainly not always. Good algorithms are
important when "n" is big - but "n" is usually small. For a small
enough size, bubblesort will beat heapsort. Good algorithms are not to
be underestimated - but not overestimated either.

And knowing assembly can give better algorithm implementations, simply
because the programmer is more aware of the underlying hardware. It can
help when you are trying to decide if you should be fiddling with
objects, or pointers to objects, for example.


  #38  
Old February 26th 19, 09:30 AM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
David Brown[_7_]
external usenet poster
 
Posts: 8
Default C is not a low level language

On 25/02/2019 23:33, Bart wrote:
On 25/02/2019 15:38, David Brown wrote:

There are almost no programming fields that require hand-written
assembly these days.Â* Even if you are writing a compiler, or low-level
libraries for a compiler, you are unlikely to need more than small
sections or snippets of assembly.Â* There are still occasions where
assembly will give you noticeably more efficient results than a
high-level language - but very, very few where the difference is big
enough to warrant using assembly.Â* Generally, if you think assembly is
the best choice then you have picked an inappropriate processor,
inappropriate tools, or an inappropriate programmer.


The sorts of arguments can be made against using C or C++. With 90% of
the code of an application, probably it doesn't matter how efficient a
language or compiler is, because the bottlenecks are in the 10%.


Agreed. For a lot of programming, C is a poor choice of language
(better than assembly, but still not good). C++ is a different matter -
it spans low-level and high-level coding, and thus covers a far wider
range of applications. But often a high-level language such as Python
makes it much easier to write safe and clear code - and correctness
beats run-time efficiency every time.

  #39  
Old February 26th 19, 10:58 AM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
Pascal J. Bourguignon
external usenet poster
 
Posts: 3
Default C is not a low level language

Robert Wessel writes:

bubble sort is very easy to write, it's just not fast.



Insertion sort is even easier to write. And it's usually twice as
fast as bubble sort.


Bubble sort is the fastest, on a vector already sorted. It's O(n) with
the best constants in this best case.

--
__Pascal J. Bourguignon__
http://www.informatimago.com
  #40  
Old February 26th 19, 11:45 AM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
Wouter Verhelst
external usenet poster
 
Posts: 11
Default C is not a low level language

On 25/02/2019 20:40, nospam wrote:
In article , Wouter Verhelst
wrote:

what matters the most are good algorithms, and knowing assembly does
not help with that.


What helps with that is understanding of how a computer works;
understanding the difference between registers and memory locations, and
understanding how a processor performs calculations and stores the
results of those calculations.


that does not matter.


Yes it does.

what matters is using the best algorithm for a given task.


The best algorithm to break RSA requires a quantum computer.

It's a very good algorithm, but on a standard computer it will not
perform very well.

The same is true for very many other algorithms: they may be very good,
but will not perform well on real hardware.

If you need to design an algorithm, it helps if you understand how the
hardware works.

a ****ty algorithm written in highly optimized assembly and using only
registers is still a ****ty algorithm.


I didn't say that. I said it helps to design good algorithms if you
understand how the hardware works. Once you do, it does not matter
whether you write that algorithm in C, Pascal, or Assembler.

It's impossible to write assembly language without at least a basic
understanding of how computers work, and it's definitely the case that
writing assembly language helps you learn that a bit more; so in that
respect it most certainly does help with writing good algorithms.


with *very* rare exception, there's no longer a need to write assembly
language anymore.


That's pretty extremely far besides the point I was trying to make...
  #41  
Old February 26th 19, 11:49 AM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
Wouter Verhelst
external usenet poster
 
Posts: 11
Default C is not a low level language

On 25/02/2019 20:38, Scott Lurndal wrote:
Again, it would need to be included in a code path that _could_
have been executed (e.g. on a conditional branch) for speculative
execution to have caused any issues.


That is true; but the code in question was behind a "this really
shouldn't happen, but in case it does, ..." type of test. Speculative
execution will still pick that up, and it caused the program in question
to crash. The unlikely condition abstract enough that the compiler could
not optimize it out, let alone the speculative execution in the
processor, but beyond that it was never going to be actually executed.

Except speculatively, which caused the crash.

I should have been clearer about that.

Speculative execution doesn't
just pick up random bits of the instruction stream and start executing
them.


Sure.
  #42  
Old February 26th 19, 11:55 AM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
Wouter Verhelst
external usenet poster
 
Posts: 11
Default C is not a low level language

On 25/02/2019 20:40, nospam wrote:
In article , Wouter Verhelst
wrote:

code that is not called can't slow anything down.


That's actually not true.


it is true. what matters is the code that *is* called.


You're saying that the code can't slow thing down if it's not called.
That's a fairly absolute statement; I just showed you a counter-example,
and so did Scott. So your absolute statement is just *wrong*.

Code that is not called but is compiled in will use up space in a memory
page. If that means the code segment of the program grows beyond a page
boundary, that may then mean an extra page fault will need to be handled
when part of the program is swapped out, which would otherwise not be
necessary.


that's more theoretical than anything real.


It does happen though, and the more "not called" code you add to a
program the larger the chances of this happening.

Also, it pollutes the processor cache, as Scott pointed out, which will
be more likely.

nearly everything is i/o bound, and then there are all the other
processes...


It's precisely the other processes which will cause (part of) your
program to get (partially) paged out if it is huge, which will cause
your slowdowns.
  #43  
Old February 26th 19, 02:02 PM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
nospam
external usenet poster
 
Posts: 4,718
Default C is not a low level language

In article , David Brown
wrote:

There are almost no programming fields that require hand-written
assembly these days. Even if you are writing a compiler, or low-level
libraries for a compiler, you are unlikely to need more than small
sections or snippets of assembly. There are still occasions where
assembly will give you noticeably more efficient results than a
high-level language - but very, very few where the difference is big
enough to warrant using assembly. Generally, if you think assembly is
the best choice then you have picked an inappropriate processor,
inappropriate tools, or an inappropriate programmer.


exactly

I think it is good for programmers to have some experience of assembly,
and to have understanding of it - it helps give a better appreciation of
how things work underneath, and can lead to the programmer writing
better high-level code (especially on smaller systems). But that is
different from actually writing assembly for real work.


what matters the most are good algorithms, and knowing assembly does
not help with that.


That is often the case - but certainly not always. Good algorithms are
important when "n" is big - but "n" is usually small. For a small
enough size, bubblesort will beat heapsort. Good algorithms are not to
be underestimated - but not overestimated either.

And knowing assembly can give better algorithm implementations, simply
because the programmer is more aware of the underlying hardware. It can
help when you are trying to decide if you should be fiddling with
objects, or pointers to objects, for example.


false.
  #44  
Old February 26th 19, 02:02 PM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
nospam
external usenet poster
 
Posts: 4,718
Default C is not a low level language

In article , Wouter Verhelst
wrote:

what matters the most are good algorithms, and knowing assembly does
not help with that.

What helps with that is understanding of how a computer works;
understanding the difference between registers and memory locations, and
understanding how a processor performs calculations and stores the
results of those calculations.


that does not matter.


Yes it does.


no, it does not.

what matters is using the best algorithm for a given task.


The best algorithm to break RSA requires a quantum computer.

It's a very good algorithm, but on a standard computer it will not
perform very well.


that's entirely different.

The same is true for very many other algorithms: they may be very good,
but will not perform well on real hardware.


nonsense.

If you need to design an algorithm, it helps if you understand how the
hardware works.


nope. the hardware is irrelevant.

a good algorithm will still be good if the hardware changes.

a ****ty algorithm makes assumptions about the hardware, and when it
does change, does not work well, or at all.

a ****ty algorithm written in highly optimized assembly and using only
registers is still a ****ty algorithm.


I didn't say that. I said it helps to design good algorithms if you
understand how the hardware works. Once you do, it does not matter
whether you write that algorithm in C, Pascal, or Assembler.


it makes little difference how the hardware works.

It's impossible to write assembly language without at least a basic
understanding of how computers work, and it's definitely the case that
writing assembly language helps you learn that a bit more; so in that
respect it most certainly does help with writing good algorithms.


with *very* rare exception, there's no longer a need to write assembly
language anymore.


That's pretty extremely far besides the point I was trying to make...


it's correct.

modern compilers generate code far better than any human can do in
almost every case.
  #45  
Old February 26th 19, 04:57 PM posted to alt.windows7.general,comp.lang.c,comp.programming,alt.comp.os.windows-10
Wouter Verhelst
external usenet poster
 
Posts: 11
Default C is not a low level language

On 26/02/2019 15:02, nospam wrote:
In article , David Brown
wrote:

There are almost no programming fields that require hand-written
assembly these days. Even if you are writing a compiler, or low-level
libraries for a compiler, you are unlikely to need more than small
sections or snippets of assembly. There are still occasions where
assembly will give you noticeably more efficient results than a
high-level language - but very, very few where the difference is big
enough to warrant using assembly. Generally, if you think assembly is
the best choice then you have picked an inappropriate processor,
inappropriate tools, or an inappropriate programmer.

exactly

I think it is good for programmers to have some experience of assembly,
and to have understanding of it - it helps give a better appreciation of
how things work underneath, and can lead to the programmer writing
better high-level code (especially on smaller systems). But that is
different from actually writing assembly for real work.

what matters the most are good algorithms, and knowing assembly does
not help with that.


That is often the case - but certainly not always. Good algorithms are
important when "n" is big - but "n" is usually small. For a small
enough size, bubblesort will beat heapsort. Good algorithms are not to
be underestimated - but not overestimated either.

And knowing assembly can give better algorithm implementations, simply
because the programmer is more aware of the underlying hardware. It can
help when you are trying to decide if you should be fiddling with
objects, or pointers to objects, for example.


false.


Now that was a well-written argument. Well done!

(plonk)
 




Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off






All times are GMT +1. The time now is 03:09 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PCbanter.
The comments are property of their posters.