Efficiency - is it still permitted? 
Author Message
 Efficiency - is it still permitted?

I hope I don't get shot down in flames because of this:

For sometime, I've been watching the two powerbasic Newsgroups. There
seems to
be a preoccupation with whether or not it is a good idea to be
efficient - and, if it
is, - just how efficient is permissible?

It's a bit difficult to admit but, when I got into programming, all we
had was ICL 1900s
( a bit like IBM 370s ) and assembler - known in ICL circles as
'Usercode'.

That was circa 1973 (ish). After that, I got into Cobol - also running
on ICL 1900s.

If I remember at all correctly, we had 512 units of memory to play
with - i.e. 512 lots
of 512 bytes (which equals roughly 256K). This permitted a
multi-programming environment
where 14 unrelated programs could run concurrently and where an EDS60
drive could carry
60Mb and was the size of two large garbage bins.

I have a son who writes chess programmes (sorry about spelling, I'm a
Brit) in C++ - an
arcane language with which I simply can not get to grips.
Nevertheless, I have to earn a crust.
I do this by being pretty good at converting files from one format to
another. I taught myself
Basic in around 1977 by building a North Star Horizon (Z80 with 48K of
memory - 2 Double Density
drives of 180K each) from a kit of parts and coping with North Star
Dos and learning North Star Basic.

IT is imbued in me that one writes for maximum efficiency and speed
and it is unbelievably difficult
to accept the bloated garbage which we are today expected to accept as
necessary.

Yes, 1973 preceded both the 'Jackson' method of structured programming
and the current necessity
for objects and things which go bump in the night.

The point of all this?

I, for one, appreciate efficiency. I can't help it - it is programmed
into me.

I can achieve things with PB with ease that I cannot otherwise achieve
at all. I have recently
become familiar with PBCC20. Great! It's quick. It works.

What is the point of all this?

Merely that I wish to represent at least a part of that forgotten
breed of programmers who
were taught to be frugal in their use of resources and who appreciate
the provision of at least one
compiler which professes to extol speed and efficiency.

Please, PowerBasic, continue to make a virtue of the shaved
millisecond from the compiler time.

It ain't the detail, it's the principle.

  --------== Posted Anonymously via Newsfeeds.Com ==-------
     Featuring the worlds only Anonymous Usenet Server
    -----------== http://www.*-*-*.com/ ==----------



Sun, 02 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?
*** Personal opinion follows ***

I think that *most* programmers here would agree with you.  Generated
code that is both fast and small is very important to all of us.

When I take all that is said about PowerBASIC (both the good and bad) and
digest it, I come to several conclusions...

First, everyone had their own way of doing things.  And they're all
convinced that everyone does things the same way they do, despite
evidence to the contrary.  That's not necessarily a bad thing.  It just
means that you have to view what they say from their angle.  Not always
an easy thing to do.

What I mean by this is...  When ever someone sends a suggestion for a
feature in PowerBASIC they are absolutely convinced that everyone else
will use the suggested feature and that PowerBASIC will sell millions
more copies as a result.  Rarely is this the case, but there is no
convincing them otherwise.

Second, PowerBASIC thrives because of user input.  Every suggestion is
kept and debated at development meetings.  Most of the best features of
PowerBASIC are a direct result of user input.  But obviously, not every
suggested feature makes it into the product.  And some features require
lots of research before they become reality.

There's been a lot of discussion for some time now about adding COM
object support to the language.  From a marketing standpoint, it's a
great idea and it will most definitely sell a lot more compilers.  But
we're not just gonna toss COM object support into the language.  As
currently implemented by Visual Basic and other computer languages, it's
very innefficient and plain ugly.  The last thing anyone needs is more
bloatware.  We're working on it, but with care.  The important thing is
that we don't "impose" objects on people who will never use them (like
myself).

Third, here's a hint for those of you who send in feature suggestions.  
Don't just send a suggestion for a new keyword.  The more information
about the keyword that you send, the greater its chances are.

Provide complete syntax, including a description of all parameters.  
Avoid keywords that may be common as variable names.  And most important,
provide "real-world" examples of its use.  Convince us that it really
needs to be added to the language.

And finally, we've made our core "philosophy" pretty clear.  And we're
not gonna change it.  Arguments about whether writing a compiler in
assembler is good or not is pointless.  We do things the way we do
things.  More importantly, when making feature suggestions, remember our
"small & fast" philosphy.  If you're suggestion is gonna require 30k of
runtime code or slows things down, it's highly unlikely we'll seriously
consider it.

If you are absolutely convinced that you know more about compilers and
selling software than we do, I seriously invite you to send us your
resume.  You *may* be right, and if you are, we'd love to make you a part
of the team.

--Dave

*** These are my own opinions, not those of PowerBASIC, Inc. ***



Sun, 02 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?

Quote:

>--Dave

>*** These are my own opinions, not those of PowerBASIC, Inc. ***

^^^^^^^^^^^^^^^^ is this a sorry ???


Sun, 02 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?

Quote:
> Generated code that is both fast and small is very important to all of us.

And thats quite a issue of m{*filter*}and pride. Something the majority of Ms
developers seem to lack a little of.

Quote:
> convinced that everyone does things the same way they do, despite

An narrow mind is not getting one to much progress. I'm a teacher, and
most of my students get puzzled when I thank them for all the stuff they
have learned me. thay can't understand the joy of learning just a tiny
little detail that makes my everyday-computer-struggle a fraction better.

Quote:
> The last thing anyone needs is more bloatware.  

Don't forget that one don't have to use whatever options there are. For
those needing (wanting) it, such an option would be generating a big
smile on a wife's face. - due to her husbands reduced time on projects.
Well, then again.. it might not end up that way..  8o)

Overall, an opinion on Pb based on the traffic on the newsgroups and my
own experience is that it's {*filter*}y hard and somewhat innefficient to use.
But as the results are as they are, I still don't regret buying it.
Althoug I must say that I'm looking forward to Daniel releasing his
contribution to overcome the worst side of PB(DLL), - the editor. Not to
forget Patrice whom can enhance the results of our struggles to please
the crowd as never before!

--
~8o)  Haakon



Sun, 02 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?
For the most part, I agree with you about efficiency. However, I
couple of caveats. Sometimes the efficient way is not necessarily the
best. Using 2-digit years is more efficient of disk space than using
4-digit years but it's created a mess. I realize that things were
different in the 1960/70s and I'm not faulting the programmers of that
time who did the best they could with the hardware limitiations of the
day. My point is that efficiency is a goal, not a god.

Secondly, sometimes time constraints require that the initial release
be somewhat less than efficient. (efficient > inefficient > nothing)
Sometimes I have had to put a program out there for use that could
have been better but was needed yesterday. In a situation like this I
always try to go back and make it more efficient as time permits.


Anything here that looks like an opinion is mine and not the company which vastly underpays me.



Mon, 03 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?

Quote:
> For the most part, I agree with you about efficiency.

How ironic that those so concerned with efficiency would choose a compiler which
provides almost no code optimization at all.


Mon, 03 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?

says...

Quote:
> > For the most part, I agree with you about efficiency.

> How ironic that those so concerned with efficiency would choose a compiler which
> provides almost no code optimization at all.

What a crock.  PowerBASIC does an immense amount of code optimization.  
And from my own tests, optimizes a darn site better than Visual Basic or
Visual C++.

If you are so down on PowerBASIC, why are you still using it?  Doesn't
that seem a bit hypocritical?

You've got nothing good to say about us or our products, yet you still
use them.  I am curious as to why.

--Dave



Mon, 03 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?

Quote:
> My point is that efficiency is a goal, not a god.

I saw something once that said of software development:

Quality (including efficiency) , Fast Delivery (Cheap), Lots of Features :
Pick any two.

MCM



Mon, 03 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?

Quote:
> > How ironic that those so concerned with efficiency would choose a compiler
> > which provides almost no code optimization at all.

> What a crock.  PowerBASIC does an immense amount of code optimization.
> And from my own tests, optimizes a darn site better than Visual Basic or
> Visual C++.

Prove it.

Provide a simple example which clearly illustrates the "optimal" nature of PB
code.  I can easily provide counter examples.

The following should demonstrate how well PBDLL6 performs two of the most
basic types of optimization; combining constants and eliminating "dead" code.

#COMPILE EXE

FUNCTION DumbCompiler AS LONG

   LOCAL I AS LONG

   FUNCTION = -1

   I = I + 2& - 2& + 2& - 2&  'NOTE: The net effect of this code is zilch
   I = I + 2& - 2& + 2& - 2&  'but the compiler isn't smart enough to
   I = I + 2& - 2& + 2& - 2&  'realize this so it generates code anyway.

   'Repeat the above line 20000 times or ...
   'add tons of other equally meaningless code.
   'Actually, anything you add here is "dead" if it
   'doesn't affect the return value. Apparently,
   'the compiler isn't smart enough to realize this either.

   I = I + 2& - 2& + 2& - 2&

END FUNCTION

FUNCTION WINMAIN (BYVAL CurInst AS LONG, _
                  BYVAL PrvInst AS LONG, _
                  CmdLine AS ASCIIZ PTR, _
                  BYVAL CmdShow AS LONG) EXPORT AS LONG

   MSGBOX "DumbCompiler = "+STR$(DumbCompiler)

END FUNCTION

If you actually do as suggested and compile, PB will readily spew out over 200Kb
of useless, worthless, bloated code to be executed with every function call.  No
other "optimizing" compiler that I regularly use will do this quite so easily.
I don't know what you call "optimization" but generating tons of worthless code
ain't it in my opinion.

Quote:
> If you are so down on PowerBASIC, why are you still using it?  Doesn't
> that seem a bit hypocritical?

> You've got nothing good to say about us or our products, yet you still
> use them.  I am curious as to why.

Simple, I use it for efficiency ... certainly not code efficiency but rather
human efficiency.  Occasionally, I need to convert old DOS BASIC code to
Windows and your products offer the quickest way to get that done; provided
there is little or no user interface involved ... and I'm willing to live with
"sub-optimal" code <g>.


Mon, 03 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?
"Everyone" has got to be kidding! No compiler should be expected
to overcome a really stupid programmer.  Or a troller. Your academic
example is useless for people solving real problems.

My own ad hoc testing shows PB produces code that executes
at least 6 times faster and as much as 20 times faster than VBA.
This testing was done with a real world problem, one I use as a very
basic and important part of my work. Did I mention that the VBA
generated dll (via Visual DLL) was twice the size even though
identical (cut-n-paste) code was used in each dll.

Take your attitude somewhere else "Everyone".

Quote:



> > > How ironic that those so concerned with efficiency would choose a compiler
> > > which provides almost no code optimization at all.

> > What a crock.  PowerBASIC does an immense amount of code optimization.
> > And from my own tests, optimizes a darn site better than Visual Basic or
> > Visual C++.

> Prove it.

> Provide a simple example which clearly illustrates the "optimal" nature of PB
> code.  I can easily provide counter examples.

> The following should demonstrate how well PBDLL6 performs two of the most
> basic types of optimization; combining constants and eliminating "dead" code.

> #COMPILE EXE

> FUNCTION DumbCompiler AS LONG

>    LOCAL I AS LONG

>    FUNCTION = -1

>    I = I + 2& - 2& + 2& - 2&  'NOTE: The net effect of this code is zilch
>    I = I + 2& - 2& + 2& - 2&  'but the compiler isn't smart enough to
>    I = I + 2& - 2& + 2& - 2&  'realize this so it generates code anyway.

>    'Repeat the above line 20000 times or ...
>    'add tons of other equally meaningless code.
>    'Actually, anything you add here is "dead" if it
>    'doesn't affect the return value. Apparently,
>    'the compiler isn't smart enough to realize this either.

>    I = I + 2& - 2& + 2& - 2&

> END FUNCTION

> FUNCTION WINMAIN (BYVAL CurInst AS LONG, _
>                   BYVAL PrvInst AS LONG, _
>                   CmdLine AS ASCIIZ PTR, _
>                   BYVAL CmdShow AS LONG) EXPORT AS LONG

>    MSGBOX "DumbCompiler = "+STR$(DumbCompiler)

> END FUNCTION

> If you actually do as suggested and compile, PB will readily spew out over 200Kb
> of useless, worthless, bloated code to be executed with every function call.  No
> other "optimizing" compiler that I regularly use will do this quite so easily.
> I don't know what you call "optimization" but generating tons of worthless code
> ain't it in my opinion.

> > If you are so down on PowerBASIC, why are you still using it?  Doesn't
> > that seem a bit hypocritical?

> > You've got nothing good to say about us or our products, yet you still
> > use them.  I am curious as to why.

> Simple, I use it for efficiency ... certainly not code efficiency but rather
> human efficiency.  Occasionally, I need to convert old DOS BASIC code to
> Windows and your products offer the quickest way to get that done; provided
> there is little or no user interface involved ... and I'm willing to live with
> "sub-optimal" code <g>.



Mon, 03 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?

Quote:
> "Everyone" has got to be kidding! No compiler should be expected
> to overcome a really stupid programmer.  Or a troller. Your academic
> example is useless for people solving real problems.

The only thing "academic" here is how the lack of optimization has been
magnified to make it blatantly obvious. The example is the most basic sort of
trivial test; real world code is much more complex.  Any real "optimizing"
compiler (like Borland's Delphi) will easily pass such a trivial test .  If PB
can't optimize this example, do you really think it fairs any better on "real
problems"?

Quote:
> Take your attitude somewhere else "Everyone".

It ain't "attitude" if it's true.  Compile the example and see for yourself.


Mon, 03 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?

Efficiency is fine, but it is no replacement for effectiveness.  Too many
strive to be efficient, while too few endeavor to be effective.  You can be
perfectly efficient, yet be completely ineffective.  All the efficiency in
the world is of no use if it has no effect or the incorrect effect.

For example, I can move a 5 lb bag of flour across a river by tying a rope
to it and dragging it through the river.  Very efficient.  Simple.  Cheap.
Shortest distance.  However, the solution is completely ineffective as the
flour will get wet and be ruined -- unless you wanted a bag of dough as the
result!!

BASIC was never intended to be an efficient language, but rather an
effective one.  The point of any HLL is to maximize the effect of each
language element, and thereby maximize the effectiveness of the programmer.
Ease of learning, ease of use, and ease of maintenance are the driving
factors in an HLL; otherwise, we could all just buck up and do it in
assembly or microcode or whatever.

Having a fast and efficient compiler that generates (arguably) fast and
efficient executables is a fine thing, provided the effectivity of the
language is not sacrificed to gain efficiency.  The same holds true for the
development environment -- lean and mean is a good thing, so long as it is
not at the expense of effectiveness.  It is better to have a bit of bloat
here and there in order to gain effectiveness, even at the expense of
efficiency.

For a real-world example, take a look at your automobile.  How much of that
sheet metal and steel beams is there for efficiency?  Most of it is there
for effectiveness -- in crashes, in weather, etc.  Imagine what automobiles
would look like if efficiency were the key criteria.

I'm all for an efficient compiler.  I wish PB could do some better
optimizing, as Everyone points out.  However, even before the additional
optimizing for speed and size, I would prefer a more effective product.
However, as Dave has made clear many times -- that is not going to happen
because efficiency is god.

Oh well.  It is still a good product, but if fear forever a niche product.
I will continue to do my "real" development (i.e., the kind that feeds my
kids and pays my bills) with other more effective products.

Scott



Quote:
> For the most part, I agree with you about efficiency. However, I
> couple of caveats. Sometimes the efficient way is not necessarily the
> best. Using 2-digit years is more efficient of disk space than using
> 4-digit years but it's created a mess. I realize that things were
> different in the 1960/70s and I'm not faulting the programmers of that
> time who did the best they could with the hardware limitiations of the
> day. My point is that efficiency is a goal, not a god.

> Secondly, sometimes time constraints require that the initial release
> be somewhat less than efficient. (efficient > inefficient > nothing)
> Sometimes I have had to put a program out there for use that could
> have been better but was needed yesterday. In a situation like this I
> always try to go back and make it more efficient as time permits.


> Anything here that looks like an opinion is mine and not the company which

vastly underpays me.


Mon, 03 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?

Quote:

>The following should demonstrate how well PBDLL6 performs two of the most
>basic types of optimization; combining constants and eliminating "dead"
code.

>#COMPILE EXE
>FUNCTION DumbCompiler AS LONG
>   LOCAL I AS LONG
>   FUNCTION = -1
>   I = I + 2& - 2& + 2& - 2&  'NOTE: The net effect of this code is zilch
>   I = I + 2& - 2& + 2& - 2&  'but the compiler isn't smart enough to
>   I = I + 2& - 2& + 2& - 2&  'realize this so it generates code anyway.

>FUNCTION WINMAIN (BYVAL CurInst AS LONG, _
>                  BYVAL PrvInst AS LONG, _
>                  CmdLine AS ASCIIZ PTR, _
>                  BYVAL CmdShow AS LONG) EXPORT AS LONG

>   MSGBOX "DumbCompiler = "+STR$(DumbCompiler)

>END FUNCTION

Optimizing this code is the very paradigm of 'beating the dead horse.'

Or, in your case, horse-shit....

MCM



Tue, 04 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?

Quote:
> Optimizing this code is the very paradigm of 'beating the dead horse.'

> Or, in your case, horse-shit....

I honestly expected something better from you.  Vulgarity (and name calling) is
usually the last resort when a more rational argument can't be found.

If you don't like my example, then provide a counter example ... or better yet,
tell me how to turn on the secret optimizer in the compiler.  I can't seem to
make it work and I have a real, practical need for it.  It would be very nice
and convenient if PBDLL would simply stop generating code for unused functions
in some of my include files but again, this seems to be asking for more
"optimization" than the compiler can deliver.



Tue, 04 Jun 2002 03:00:00 GMT  
 Efficiency - is it still permitted?

Quote:

>Efficiency is fine, but it is no replacement for effectiveness.  Too many
>strive to be efficient, while too few endeavor to be effective.  You can be
>perfectly efficient, yet be completely ineffective.  All the efficiency in
>the world is of no use if it has no effect or the incorrect effect.

When I spoke of the best way of doing things, part of what I said
dealt with actually accomplishing the goal (a soaking wet bag of flour
is not accomplishing the goal unless you are really bad at planning),
that is, actually turning out a finished program. I think that pretty
much covers what you mean by effectiveness.


Anything here that looks like an opinion is mine and not the company which vastly underpays me.



Tue, 04 Jun 2002 03:00:00 GMT  
 
 [ 92 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7]

 Relevant Pages 

1. 3D Scanners vs. Digital Stills

2. Ans permits what range of KEY codes?

3. UNIX semantics do permit full support for asynchronous I/O

4. Does the LRM permit parameter passing by reference?

5. Allocatable arrays not permitted in F90 structures!

6. Q: operation not permitted error...

7. Is Tcl_DupInternalRepProc *dupIntRepProc permitted to be NULL

8. Does Python license permit embedding in commercial product ?

9. Help VA 3.0a does not permit logon control when connecting to DB2/2

10. I am not deaf, but am I mute?

11. Efficiency

12. APL execution efficiency revisited

 

 
Powered by phpBB® Forum Software