Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C Compilation..

Reply
Thread Tools

C Compilation..

 
 
Richard
Guest
Posts: n/a
 
      08-25-2008
James Kuyper <(E-Mail Removed)> writes:

> Richard wrote:
>> Keith Thompson <(E-Mail Removed)> writes:
>>
>>> Richard Heathfield <(E-Mail Removed)> writes:
>>>> Richard Tobin said:
>>>>> In article <(E-Mail Removed)>,
>>>>> Richard Heathfield <(E-Mail Removed)> wrote:
>>>>>
>>>>>> In any case, correctness is far more important than speed.
>>>>> Not always. For some purposes, as someone used to have in their
>>>>> signature, "late answers are wrong answers".
>>>> Wrong answers are wrong answers, too. Getting them quicker doesn't
>>>> make them righter.
>>> You're both right. Sometimes speed is simply part of the
>>> requirements. (And sometimes it isn't.)

>>
>> Speed is always beneficial in *everything* ...

>
> Speed is not always beneficial - in real-time programming, there's
> often an optimum time to do something, and extra speed beyond what's


Assuming proper "wait" facilities are available this is not true. It
running efficiently even leads to power saving and reduced heat.

> needed to meet that deadline provides no extra benefit. The extra


Not the point. The point is to consider. If we talk about portability we
can also consider that there is NO POINT wasting clock cycles since it
might be used in a more constricted environment later.

> speed is generally not harmful, if handled correctly by inserting an
> appropriate waiting period somewhere in the process, but it isn't
> beneficial.
>
>> ... if the speed gain is not
>> offset by maintenance or stability issues.

>
> Or, getting back to the topic at hand, correctness issues?


Sigh. Did I need to state the obvious? That I assume the faster program
also is correct?

>
>> The reason desktops are 5000 times more powerful yet nothing seems to
>> run much quicker than the first PCs is wasteful and lazy approaches.
>>
>> If you use C and do NOT consider efficiency in most cases then you are
>> incompetent.

>
> No one has suggested that efficiency be ignored, only that it's a
> lower priority than correctness.


I find it astonishing that you even think for ONE second that I mean a
fast WRONG program is better than a slow CORRECT one. Clearly this is
NOT what I mean.
 
Reply With Quote
 
 
 
 
Kenny McCormack
Guest
Posts: n/a
 
      08-25-2008
In article <g8um8b$q7a$(E-Mail Removed)>,
Richard <(E-Mail Removed)> wrote:
....
>I find it astonishing that you even think for ONE second that I mean a
>fast WRONG program is better than a slow CORRECT one. Clearly this is
>NOT what I mean.


It's an obvious man-of-straw, but that's all they can do.

Sucks to be so mentally limited, but there you have it.

 
Reply With Quote
 
 
 
 
jameskuyper@verizon.net
Guest
Posts: n/a
 
      08-25-2008
Richard wrote:
> James Kuyper <(E-Mail Removed)> writes:
>
> > Richard wrote:
> >> Keith Thompson <(E-Mail Removed)> writes:
> >>
> >>> Richard Heathfield <(E-Mail Removed)> writes:
> >>>> Richard Tobin said:
> >>>>> In article <(E-Mail Removed)>,
> >>>>> Richard Heathfield <(E-Mail Removed)> wrote:
> >>>>>
> >>>>>> In any case, correctness is far more important than speed.
> >>>>> Not always. For some purposes, as someone used to have in their
> >>>>> signature, "late answers are wrong answers".
> >>>> Wrong answers are wrong answers, too. Getting them quicker doesn't
> >>>> make them righter.
> >>> You're both right. Sometimes speed is simply part of the
> >>> requirements. (And sometimes it isn't.)
> >>
> >> Speed is always beneficial in *everything* ...

> >
> > Speed is not always beneficial - in real-time programming, there's
> > often an optimum time to do something, and extra speed beyond what's

>
> Assuming proper "wait" facilities are available this is not true. It
> running efficiently even leads to power saving and reduced heat.


I'm sure that some systems have proper "wait" facilities. However,
your assertion "Speed is always beneficial" requires that power-saving
wait states exist in ALL such contexts, not just "some" of them, not
even "most" of them. While most of my experience has been in a very
different environment, I have done some real-time programming, and I
know that, at the very least, the system I was using had no such
feature. It did give me the option of letting other lower-priority
tasks run while my task was waiting for something to happen, but it
had no feature that would allow it to consume any less power if all
tasks happened to be waiting at the same time, than it would have
consumed in a "busy-wait" state.

> > needed to meet that deadline provides no extra benefit. The extra

>
> Not the point. The point is to consider. If we talk about portability we
> can also consider that there is NO POINT wasting clock cycles since it
> might be used in a more constricted environment later.


Portability and "real-time" don't go together. At the simplest level,
this is trivially true: no program intended to control of a particular
device could possible work as intended on a system which has no such
device installed. At a higher level, the critical problem is that the
C standard doesn't say anything about how long anything takes to
execute, not even "int a=0;". In order to work in a real-time
environment, code has to rely upon non-portable assumptions about how
fast various things occur, and use non-portable interfaces to
communicate with the devices involved.

> > speed is generally not harmful, if handled correctly by inserting an
> > appropriate waiting period somewhere in the process, but it isn't
> > beneficial.
> >
> >> ... if the speed gain is not
> >> offset by maintenance or stability issues.

> >
> > Or, getting back to the topic at hand, correctness issues?

>
> Sigh. Did I need to state the obvious? That I assume the faster program
> also is correct?


Yes, you do, since the context of your comment was objections to
Richard Heathfield correctly making precisely that "obvious" point. If
you were not endorsing and contributing to those objections, then that
fact was not clear from the words and context of your message.

> >> The reason desktops are 5000 times more powerful yet nothing seems to
> >> run much quicker than the first PCs is wasteful and lazy approaches.
> >>
> >> If you use C and do NOT consider efficiency in most cases then you are
> >> incompetent.

> >
> > No one has suggested that efficiency be ignored, only that it's a
> > lower priority than correctness.

>
> I find it astonishing that you even think for ONE second that I mean a
> fast WRONG program is better than a slow CORRECT one. Clearly this is
> NOT what I mean.


I can't imagine any sane person believing that - yet that's precisely
what it means to object to the statement "correctness is far more
important than speed"; and bizarrely enough, that's what some people
have been doing. That statement was nothing more or less than a
different way of saying that "a fast WRONG program is not better than
a slow CORRECT one". Anyone interpreting it in some other fashion
wasn't paying attention (as, for example, the person who confused
"correctness" with "portabilty").
 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      08-25-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) writes:

> Richard wrote:
>> James Kuyper <(E-Mail Removed)> writes:
>>
>> > Richard wrote:
>> >> Keith Thompson <(E-Mail Removed)> writes:
>> >>
>> >>> Richard Heathfield <(E-Mail Removed)> writes:
>> >>>> Richard Tobin said:
>> >>>>> In article <(E-Mail Removed)>,
>> >>>>> Richard Heathfield <(E-Mail Removed)> wrote:
>> >>>>>
>> >>>>>> In any case, correctness is far more important than speed.
>> >>>>> Not always. For some purposes, as someone used to have in their
>> >>>>> signature, "late answers are wrong answers".
>> >>>> Wrong answers are wrong answers, too. Getting them quicker doesn't
>> >>>> make them righter.
>> >>> You're both right. Sometimes speed is simply part of the
>> >>> requirements. (And sometimes it isn't.)
>> >>
>> >> Speed is always beneficial in *everything* ...
>> >
>> > Speed is not always beneficial - in real-time programming, there's
>> > often an optimum time to do something, and extra speed beyond what's

>>
>> Assuming proper "wait" facilities are available this is not true. It
>> running efficiently even leads to power saving and reduced heat.

>
> I'm sure that some systems have proper "wait" facilities. However,
> your assertion "Speed is always beneficial" requires that power-saving
> wait states exist in ALL such contexts, not just "some" of them, not
> even "most" of them.


Speed is many things in an programmers conversation. It can be
interpreted as economy of movement too if you want to be really open
minded. e.g uses less memory. Other tasks therefore get more available
or more timeslots etc etc. To think about optimization of kinds at an
early enough stage in designing a C system is not a death knoll as many
here would have you believe. The fact that C is chosen is usually for
efficiency and speed.

Considering "speed" is imperative in many designs. Not to do so is, as I
said before, incompetent in many, many cases. Not all I grant you. But
to *CONSIDER* it in all cases can never be wrong. You might decide for
reasons highlighted in my previous post not to follow it up but to
consider it is a must.

 
Reply With Quote
 
August Karlstrom
Guest
Posts: n/a
 
      08-25-2008
Richard Heathfield wrote:
[...]
> Clarity, correctness, modularity - these are the cornerstones.


That is funny because non of these are the strong points of C (on the
other hand availability, expressiveness and efficiency are).


August
 
Reply With Quote
 
Peter Nilsson
Guest
Posts: n/a
 
      08-25-2008
Richard Heathfield <(E-Mail Removed)> wrote:
> August Karlstrom said:
> > Richard Heathfield wrote:
> > > Clarity, correctness, modularity - these are the
> > > cornerstones.

> >
> > That is funny because non of these are the strong
> > points of C (on the other hand availability,
> > expressiveness and efficiency are).

>
> Perhaps it would be truer to say that none of these
> are the strong points of C *programmers*.


It's a poor language that blames the tools who use it.

--
Peter
 
Reply With Quote
 
August Karlstrom
Guest
Posts: n/a
 
      08-26-2008
Richard Heathfield wrote:
> August Karlstrom said:
>
>> Richard Heathfield wrote:
>> [...]
>>> Clarity, correctness, modularity - these are the cornerstones.

>> That is funny because non of these are the strong points of C (on the
>> other hand availability, expressiveness and efficiency are).

>
> Perhaps it would be truer to say that none of these are the strong points
> of C *programmers*.


That is true to some extent. For instance, achieving modularity in C
requires quite a lot of discipline and knowledge of best practice. In
Oberon, to mention another system programming language, the module is a
language construct used in every program.


August
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      08-26-2008
On 24 Aug, 09:45, "Lassie" <(E-Mail Removed)> wrote:
> "Keith Thompson" <(E-Mail Removed)> schreef in berichtnews:(E-Mail Removed)...


> > Re-read the original question that started this thread. *Do you really
> > think the OP was asking about ABIs?

>
> The OP is not experienced in C,


ok

> I believe he didnt know himself what he was
> asking.


I think he was perfectly clear in his own mind about what he was
asking. He was asking for the code generation strategy for C. I'm sure
compiler writers have such a strategy for each architecture they
support.
But (we know) it isn't standardised.

> But as far as his question concerns, ABI answers it pretty much yes.


no. ABIs only seem to cover call and return conventions (maybe program
startup as well). General code isn't covered at all.

> It's not a 100% C to machine instruction standard no,


nor even 20%


> but they cover a lot
> of binary interfacing yes.


*interfacing*- thats not what most code does


--
Nick Keighley

 
Reply With Quote
 
 
 
Reply

Thread Tools

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

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments