Prev: Pathfinding algorithm bugged?
Next: Counting lines of code produced as a metric of programmer quality
From: jpwoodruff on 23 Mar 2010 14:34
On Mar 23, 10:54 am, Pascal Obry <pas...(a)obry.net> wrote:

<jpw removed discussion of bounds checking>

> But anyway this is not even an issue. For performance you can always
> remove the checks using the right compiler option. Then you have the
> best of both worlds. During development the checks are really helpful,
> in production you remove them.
>

I hope I'm not the only old-timer who remembers:

"This is the case of the sailor who wears his life jacket while
rigging his boat,
then leaves it ashore when he goes sailing."

John
From: Adam Beneschan on 23 Mar 2010 15:33
On Mar 23, 10:41 am, Jim Balson <lab...(a)cherrystonesoftware.com>
wrote:
> J-P. Rosen wrote:
> > balson a écrit :
> >>      IOW, stay away from the likes of Java, C#, Pascal. Unless you have a
> >> very specific reason for going in that direction. Your performance will
> >> suffer.
>
> > I don't see why you put Pascal in the same basket. Pascal is not part of
> > the benchmark, therefore there is no evidence for what you say, and
> > Pascal does not require an interpreter or semi-interpreter.
>
> I included Pascal because once you get up into languages that do bounds
> checking, performance will degrade. Pascal is one of those languages
> that does bounds checking. It comes down to this:
>
> a) Either the programmer writes code to not exceed array bounds, or
> b) Use a language that does it for you.
>
> The choice of (a) will cost you a little bit of time developing.
> The choice of (b) is going to cost you in performance when done.

Aside from the fact that (as Pascal Obry pointed out) compilers for
languages that do these checks for you usually provide a way to
suppress those checks, (a) is a little bit naïve. Or maybe a lot
naïve---I don't know. But it's like saying

(c) The programmer writes code that just works perfectly all the time.

I wish I could! I've been in this business for over 30 years and I
still haven't figured out how not to make mistakes. I suspect that it
may have to do with my being a member of _Homo sapiens_. But I'm sure
that the folks at Microsoft, Oracle, etc., try to write code that
"doesn't exceed array bounds" (and doesn't do double deallocation,
etc.). But all they have to do is make a mistake in one case, and the
result is software with a vulnerability that bad guys figure out how
to exploit, and now the amount of performance time you save by not
doing bound checks is dwarfed by the amount of total time thousands of
people spend trying to clean malware off their computers, restore
destroyed data from backup, etc.

So bounds checking is a good thing. Even so, it's good to have a
choice. Pascal and Ada, as usually implemented, let you choose
between the extra safety of bounds checks and the added performance of
eliminating them in programs that have been tested. C doesn't.

-- Adam

From: Patrick Scheible on 23 Mar 2010 16:29
Warren <ve3wwg(a)gmail.com> writes:

> balson expounded in news:4BA8BA91.4050905(a)cherrystonesoftware.com:
>
> > Andrea Taverna wrote:
> >> Hi folks!
> > [snip]
> >> In the past I used C, but now I have decided to change language.
> >> I'm looking for a "better" one.
> >>
> >> Here follow the features it should have, ranked approximately by
> >> relevance:
> >>
> >> 0) open-source support and an alive community
> >> 1) directly compiled to efficient code
> >> 2) statically typed and object-oriented, better if multi-paradigm
> >> 3) general-purpose libraries (possibly standardized, either by
> >> standard or de facto), including containers and some math
> >> abstractions. 4) garbage collected. As an alternative, provide memory
> >> management policies via libraries (e.g. memory pools and such)
> >> 5) optional run-time checks and some kind of control over compilation
> >> and low-level issues
> >> 6) "relatively simple and consistent"
> >
> > Where's performance on this list?
>
> Performance is mentioned in "1) directly compiled to efficient
> code".
>
> > IOW, stay away from the likes of Java, C#, Pascal. Unless you
> > have a
> > very specific reason for going in that direction. Your performance
> > will suffer.
> > Jim
>
> I don't think many people would be surprised by these results.
> After all Java, C# and Pascal (variants) are still largely
> interpreted languages, even if they use some sort of compiled
> intermediate code.

Pascal is not an interpreted language. One of Pascal's selling points
was that it was one of the first languages that could be parsed by a
simple recursive descent parser without backtracking.

-- Patrick
From: Patrick Scheible on 23 Mar 2010 16:33
Pascal Obry <pascal(a)obry.net> writes:

> Jim,
>
> > I included Pascal because once you get up into languages that do bounds
> > checking, performance will degrade. Pascal is one of those languages
> > that does bounds checking. It comes down to this:
> >
> > a) Either the programmer writes code to not exceed array bounds, or
> > b) Use a language that does it for you.
> >
> > The choice of (a) will cost you a little bit of time developing.
> > The choice of (b) is going to cost you in performance when done.
> >
> > If we were to add another language to our benchmarks, Pascal would be
> > the logical choice. And we may do it at some point in the future. We're
> > certainly going to add many more algorithms to the testing as time permits.
>
> I dont' know for Pascal, Ada does bound checking too. Nevertheless, in
> some cases the checks can be removed automatically, for example:
>
> type Tab is array (1 .. 10) of Integer;
>
> T : Tab;
>
> for K in T'Range loop
> T (K) :=
> end loop;
>
> Here "T (K)" won't trigger a runtime check as the compile can see at
> compile time that K is always in the proper range.
>
> But anyway this is not even an issue. For performance you can always
> remove the checks using the right compiler option. Then you have the
> best of both worlds. During development the checks are really helpful,
> in production you remove them.

It's been said that this approach is like having lifeboats on an ocean
liner while it is in sea trials, and then taking them out when it
starts to carry passengers.

-- Patrick
From: Patrick Scheible on 23 Mar 2010 16:34
jpwoodruff <jpwoodruff(a)gmail.com> writes:

> On Mar 23, 10:54=A0am, Pascal Obry <pas...(a)obry.net> wrote:
>
> <jpw removed discussion of bounds checking>
>
> > But anyway this is not even an issue. For performance you can always
> > remove the checks using the right compiler option. Then you have the
> > best of both worlds. During development the checks are really helpful,
> > in production you remove them.
> >
>
> I hope I'm not the only old-timer who remembers:
>
> "This is the case of the sailor who wears his life jacket while
> rigging his boat,
> then leaves it ashore when he goes sailing."

Not the only one. How many viruses spread by buffer overflow exploits
that would be impossible in a bounds-checked language?

-- Patrick
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: Pathfinding algorithm bugged?
Next: Counting lines of code produced as a metric of programmer quality