PowerBASIC versus C & C++

[Mike Joseph]

I only have limited C (and extremely limited C++) coding
abilities, but I have done a few PB v C speed comparisons.
My first was the Blowfish algorithm which I translated to
PB from C and the second was a string binary representation
of ascii characters (those hanging out in #visualbasic are aware
of the almost maniacle contest which was going on and lasted
for nearly 7 days).

In any case, as far as i can tell, PB is not faster than
C code that is compiled under Visual C++ 6.0. PB is fast,
but it seems significantly slower than equivalent C apps.
My own Blowfish translation required inline asm in order to
beat the VC compiled C version.

Some people on this board are always saying how PB is
as fast or faster than C, but at this point, I think its just
alot of talk with no real substantiated evidence to back
it up. I realize PowerBASIC has never made this claim, only
some of the people on this board. So to those people on this
board, put up some actual benchmarks WITH C and PB source, else
give that argument a rest. (or keep it up with the knowledge that
other more scrutinizing individuals are going to take what you
say with a grain of salt.)

As far as I'm concerned, PB is fast enough and with the inline
asm support, you can write anything you want with the true
potentional to make it peform as fast as possible. But in
terms of strict C (or C++) performance comparison, PB comes up
short. One thig is certain, PB definetly produces the smallest
EXE's. That alone should tip people off that PB exe's may not
be as fast as C exe's compiled under VC (especially when compiler
options for fast code are used.) In most real world scenarios,
you cant have both the fastest code and the smallest exe at
the same time. Again, if you think PB is faster, prove it.

Recently in all of these OOP threads, this board has practically
degenerated into a run of the mill programming language flame
war. PB versus VB, PB versus COM, PB versus OO, PB versus
bloatware. Never mind the fact that all of the afore mentioned
tools have their place in the world. Never mind the fact that
people can make a good living using all of the afore mentioned
tools. Some of the zealots on this board refuse to accept the
idea of using the "right tool for the job." Sounds too much like
the C zealots who think coding in VB is a sin. Code is the right
way or no way attitude. Thankfully most of the world doesnt
think that way which is evident by the huge (and well paying)
VB job market.

Back to C and C++. I can accept the bloatware argument when
talking about PB versus VB, but PB versus C++? (and im not
talking about COM, just OOP under C++.) To me, calling OOP
under C++ bloatware is just rediculous. I'll say this, OOP
under C++ may very well be faster than PB. Sure the exe size
are larger, but for the benefit of speed its a very desireable
tradeoff. You prefer slower performance with a smaller exe?
Thats fine, but you're probably in the minority.

Prove me wrong. Lets get some C, C++ and PB translations up here
and see the results instead of just talking out of our rears and
speculating. Talk is cheap. I have a funny feeling that nobody
will want to persue this performance comparison. In fact, i get
the feeling that some people on this board would rather come up
with clever arguments as to why C++ OO code would simply have to
be slower than the best PB equivalent. If anyone is willing to
help on the C/C++ side, I can help with the PB translations.

-Mike


------------------

[Mike Joseph]

Furthermore, I fault PowerBASIC for alot of these discussions. I
like the compilers they produce and if the next version is either
a Linux version or an OO version, then i'll definetly buy it.

But i do not care for the way they disseminate information about
future products. I mean I have to wonder, is it actually
necessary for all of us to preach and defend our wishlist items
on this BBS? Thats a scary thought, but if its true, then all i
have to say is Go Stephane Fonteyne Go! And dont let the
board Nazis get you down. You're speaking for more people than
you realize. There are many PB users who arent as knowledgeable
as some of your opponents and are hesitant to join in on the
debates for fear of getting crushed.

This really does feel like a contest between the old school
programmers and the new. We've got people in here describing how
PB should/could implement objects into the language. Well i for
one sure as heck hope that PowerBASIC doesnt find any of the
technical arguments very useful. That to me would indicate too many
bad things. But again, if this is a contest, then PowerBASIC
should send email notifications to everyone to submit their
wishlist items because its certainly not fair that the loud few
should win over the silent majority (and even the majority who
do not lurk on these boards but which do use the compilers)

But in actuality, I know better. The folks at PowerBASIC arent
going to implement or not implement any _major_ feature based on
a dozen or so people sounding off on this board. (or at least i
would hope not.)

And to the lurkers out there who havent been participating on
this BBS, if you want something implemented, please send that
list to the support staff directly. It may or may not count
for nothing, but its worth a try.

-Mike



------------------

[Steve Hutchesson]

Mike,

Effectively what you are comparing is runtime library functions of
different types. Native C uses either zero terminated strings or buffers
with a length variable and depending on the type of code you want to
write, some operations with this string capacity are faster than native
basic dynamic string.

Classic case is string concantenation, worst case is adding one character
to a string at a time where the algo will get progressively slower as the
operation proceeds. Other end of the market is where you want to do
multiple conversions from text to numeric and back again after formatting
the text. It can be done in zero terminated strings but its messy and no
joy to get going.

There is an unusual inversion in the comparison offer that you are making,
you are assuming that VC6 C or C++ is faster than PowerBASIC code while
admitting that you are limited in your experience of both. This is a bit
difficult to follow.

My own C is getting very rusty and I doubt that I could get it up to pace
in any real hurry, even if I had the time to waste. I write assembler in
preference to C as it does not suffer from the runtime variations of C
libraries.

Now I am sure that if you want to produce some clear C or C++ examples,
ther are enough people floating around this forum to have a look at it.

===========================================================================
In most real world scenarios, you cant have both the fastest code and the
smallest exe at the same time. Again, if you think PB is faster, prove
it.
===========================================================================

If you are comparing the difference between assembler instructions from
different eras of processors of x86, you will be right in some circumstances
but if you are referring to things like inlining code as against calling
a function that has higher stack overhead, it is a matter of how you write
the code, not what it is written in.

===========================================================================
I'll say this, OOP under C++ may very well be faster than PB. Sure the exe
size are larger, but for the benefit of speed its a very desireable
tradeoff. You prefer slower performance with a smaller exe? Thats fine,
but you're probably in the minority.
===========================================================================

As you appear to willing to defend bloat as "size optimisation", feel free
to produce some of this stuff for comparison, the more OOP(s) the better.
Perhaps the following comment can form the basis of your view on where the
real performance lies.

===========================================================================
Thankfully most of the world doesnt think that way which is evident by the
huge (and well paying) VB job market.
===========================================================================

I am sure that everyone who frequents this forum will be waiting with baited
breath for some high speed bloatware. If you prefer to use non OOP C, try
using the construction,

__asm{
; asm code here
}

You may end up with something worth comparing.

Regards,

[email protected]

PS: Please define your benchmark technique, I personally use files in the range
of 100 megabytes to test my PB/asm algos in real time.

------------------

[Mike Joseph]

Steve, I will reserve any attempt at producing some C and C++
benchmarks til i see if there are any competant C/C++ programmers
out there who are willing to assist.

That said, I've already stated that my C reference Blowfish
implementation was faster than my PB translation. In fact,
my PB version was clocking in at ~7 seconds compared to 2
seconds for the PB version before converting the main loop
to inline asm.

The other code test which I mentioned was the string representation
of a binary value. I translated someones C version and it was
nearly 3 times as fast as my PB version.

True, it wasnt C++ versus PB though (just C and PB). But yes, I am
going to _assume_ that PB is slower than C++ also. I had a feeling
someone would respond in a fashion such as yours and i stated
as much in my closing paragraph. As far as im concerned,
in the absence of benchmarks, my assumption is just as valid as
yours. In my post im quoted as saying "prove it" and you are
now effectively redirecting the challenge and telling me to
"prove it." Well heck, if you want me to just dig up some
samples from the internet I can certainly do that. Im definetly
not going to try and think up my own benchmarks and then
write them in C++.

As for your bloatware comment, I'll just invite people to reread what
i actually wrote and see how that fits in with your selective
quoting and commenting. And besides, I think most people
consider high speed bloatware an oxymoron. But if there is
such a thing, then we're talking about a tradeoff... one which
apparently you dont feel is worth it under any circumstances.
You wouldnt want me to quote you as saying "I prefer small
slow exe's to fast fat ones" would you?

Also, maybe you should define bloatware because I honestly dont
know what you mean by it.

-Mike

------------------
P.S. I forgot to mention, you seem to be implying that the
PB compiler is a superior "fast code" optimizing compiler than VC++
and I think this is simply not so. So you can come up with all
sorts of theoretical reasons why PB should be faster, but in the
end, it all boils down to the optimizing capabilities of the
compiler.
P.S.S Im not sure what you're trying to prove with the asm code
snippet.



[This message has been edited by Mike Joseph (edited September 25, 2000).]

[Florent Heyworth]

Hi guys

these conversations are getting heated... but then it shows how
strongly people feel about these topics.

Joseph, I do agree with a lot of your comments. I hear a lot
of shouts of bloatware, many unsubstantiated. I also agree that
the people hounding Stephane are getting just as repetitive
as he is - live and let live...

I program in several languages including C/C++/PB and others.
I started out with C so I'd be quite willing (and able) to assist
in drawing up some benchmark programs.

I can tell you this from my experience though: straight C and
often straight C++ (without using ASM) is often faster than PB.
It has not much to do with the language, rather the compilers'
optimizers are getting better. PB apps ususally can't be beat
for the same speed to size ratio (apart from ASM) though.

I did not envision the thread "What OOP in PB might look like" as
"telling PowerBASIC how they *should* implement OO in PB" - rather
I wanted to explore how we users *might* implement OO using the
existing PB compilers.

I also think it'd be useful if people would share their ideas about
OO in PB (what it might look like, what they think they might get from
it) - it's also useful having people say what they don't like about
OOP (although their comments should be substantiated).

Cheers

Florent



------------------

[Chris Boss]

With version 5.0 and beyond of VB, Microsoft is much closer to PB in
speed, since VB 5.0 (native code compiler) is much faster than
VB 4.0 (Pcode compiler). What I found interesting was that VB uses
a C compiler in the background now, to produce native code.
So this means even comparisons to VB native code, are comparisons
to a C compiler.

So how does PB hold up to comparison to a C compiler ?

If you set options for "smaller" code in a C compiler or even VB
then the speed of those apps slows down a good bit. This seems
to indicate that faster code usually means "larger" code.
PB compares very well to C (or VB) apps that were compiled with the
"small size" options.

The problem is that when you select the options for "faster" code
, then of course a C compiler can beat PB code. PB doesn't have
an option for "faster code" (but bigger code), since their goal
is always to keep the code size small.

Faster code seems to always generate larger size in code, so its
one or the other.

But to be truly fair, it is not enough to simply compare languages
simply because of code speed for the exact same code. Why ?

In many instances, the speed of an app is determined by richness of
the languages command set. A good example is PBs string functions.
I don't know what I would do without PBs REPLACE$ command. VB doesn't
have this !

If the language is richer in its command set, then a programmer has
more to choose from to optimize their apps. PBs integration of
an inline assembler, makes it superior to any Basic compiler.

PBs use of Pointers is one its major advantages over other Basic
compilers ! Its data set is richer, with things like AsciiZ.

Now, back to comparing PB to C.
(PB obviously is superior to VB , IMO!)

Even if a benchmark were to show that a C compiler was say 5% faster
than PB (and I doubt a C compiler would be much faster than that),
this means absolutely nothing to a BASIC language programmer. The
reason Basic is used, is because of the Language in its ease of
coding. BASIC has always been the number 1 language of choice for
those who want easy to read code and easy to maintain code. The
fact that a BASIC compiler (PB) can even come close to the speed
of a C compiler, is amazing.

One of the hardest things to "benchmark" is the advantages of a
programming languages command set for faster and better code
writing. My personal opinion, is that C code is much harder to
debug than Basic code. C's syntax is a more terse style than Basic.

If you were to consider the time spent debugging apps, then likely
Basic programmers are more productive than C (IMO).

When I write code in PB, I don't even have to use the debugger
to find bugs. The language is so easy to read and has so many features
that I find it easy to find bugs and fix them. I can go back
and read code I wrote 10 years ago (with no comments) and easily
figure out what I was doing with it.

Even if someone could prove to me that a C compiler will produce
slightly faster code than PB, I wouldn't switch !

------------------


[This message has been edited by Chris Boss (edited September 25, 2000).]

[Mike Joseph]

Steve, I re-read what you said and i definetly did miss out on
part of what you were saying.

With regards to my comments on writing fast code versus lean
code (in terms of exe size) then I understand what you mean by

"it is a matter of how you write
the code, not what it is written in."

This is something I should have mentioned. Based on my limited
comparisons, equivalent C code compiled under VC++ 6.0 will be
faster than PB. Why? It could very well be that VC++ is making
optimizations which the PB user could have done (would have to have
done) manually in order to get similar performance results. In effect
the PB programmer would have to be a better programmer. This
includes the possibility that the PB programmer is required to
use inline asm to get those results.

What does that actually prove? If you're comparing compilers,
it should be a matter of comparing equivalent code and not a
case of the PB programmer having to unwravel his own loops or
implement his own asm portions which the VC++ compiler effectively
does for you.

In summation, I would argue that the VC++ compiler is a more
forgiving compiler in the same sense that the PB compiler is
more forgiving than VB. Would anyone here argue that the only
thing seperating VB from PB is the runtime? Clearly, writing
strict procedureal code in VB (no classes) is still slower than
PB code. Is that the result of VB's association with the runtime
or is PB a better optimizing compiler?
-Mike


------------------

[Mike Joseph]

Florent,

Yes, this is getting heated and I've re-read some of what I wrote
and I see that i am getting over excited I'm going to
take it down several notches. I want to express my opinion and
disagree when inclined, but not at the expense of civility.
Hopefully everyone will cut me a little slack this time around.
-Mike

------------------

[Chris Boss]

I think another consideration is CPUs.

It is quite possible that some compilers "test" for
which CPU is running and then it determines which section
of its own "Runtime" code to use during execution
(dynamically at runtime and not at compile time).

By switching to a different runtime code depending on
what CPU is being used would add to code size (explanation
of larger code), but could "significantly" improve execution
speed in some instances. Just by using machine language
instructions unique to a particular processor can make
a huge difference. Just the fact that some compilers have
options to select which CPU will be used, means the compiler
maker does use different code for different CPUs. It is
also possible they have more than one set of runtime code
included in a compiled app designed for speed and it tests
to see which CPU is in use.

I am sure some of the "assembler" experts could give us more
detail about the difference in CPUs and how a compiler can take
advantage of those differences.




------------------

[Kev Peel]

I can't see how you can say (the equivalent of) 'Write in C/C++ because it is faster', I write programs in PowerBASIC because It is a familar *English* language, I could write reams and reams of code in PB which would take months in C !

It's not always about the speed of you programs that count, I can write an acceptably fast program in PB and have it distributed over the net with little fuss, in only a month. If your PB programs are that lacking in speed, then maybe you should take a look at the way you code, even a bad assembler programmer can write slow code!

You compare C users to PowerBASIC users, well there may be fewer of us, but I'll bet we have the smaller & faster programs - I'd expect 7 or 8/10 C/C++ programmers use MFC, and lets not go there

Just my two pence worth.


------------------
Kev G Peel
KGP Software, Bridgwater, UK.
www.go.to/kgpsoftware

[jcfuller]

How granular are the C++ Compilers/Linkers?

If I have a Class With 10 Methods, but only call one from my app, are all
the functions still included in the exe?

James


------------------


[This message has been edited by jcfuller (edited September 25, 2000).]

[Florent Heyworth]

Hi James

in general C/C++ compilers allow a high level of granularity when
linking code. You can choose to compile your programs in discrete
objects and these discrete objects will in turn be linked in terms
of the functionality you use.

With OOP, that's a more difficult question and I'd have to check
on that - I don't know the answer offhand - I would expect that
you'd get at the very least the constructor,destructor,allocator
code plus your one method at least.

Cheers

Florent

------------------

[Mike Joseph]

Kev, I'm not sure who you're responding too since I couldnt
find any of the references you made in any post under this
thread. The focal point of my initial post is that contrary to
the popular hype on these boards, I do not believe PB is as
fast or faster than C or even C++ apps which are compiled under
VC++ 6.0. Thats it.

I just think more good can come out of these discussions if
people were less defensive when it came to talking about any
weaknesses and/or limitations in PB (particularly when compared to
other languages).

If everything is perceived as an attack, then i guess serious
criticism should be squashed. Fortunately, the PB staff have
not been squashing these threads and have actually been very
accomodating. We're all software developers here so we should
all be able to appreciate getting feedback (both positive and
negative) from our users.

You know PB is a great compiler because even the worst criticisms
are quite positive if you think about it. People want more
because they cant get enough of a good thing. And nowhere on this
board will you find any post (past or present) which truely bad
mouths or flames PB.

-Mike

------------------

[Guest]

...and the war rages on; the casualties mount; the Red Cross
is running out of medical supplies and the rest of the world
looks on and puzzles at the futility of it all.

------------------

[Steve Hutchesson]

Mike,

I have never made any apology for defending the PowerBASIC compilers
against the near endless criticism of the old C camp and nor do I intend
to. I have written for years in C compilers in the past and I got
reasonably used to the level of patronising nonsense about using line
numbered interpreters.

I am fully in support of the PowerBASIC policy of putting as much grunt
into the compilers for basic programmers as possible. I have in the past
worked for years with basic programmers who were capable of near miraculous
programming to put some power into deliberately crippled dialects of basic.

The faith in compiler optimisations is by no means a universally held
position, many I know and with myself included hold the view that the best
compiler optimisation available is the one you can turn off.

PowerBASIC gives the low level programmer a very useful capacity to write
their code without the compiler interfering with the order of code or
the manually written optimisations in the code. Inflicting old C/C++
style optimisations on PowerBASIC would be a mistake in that it removes
another capacity from the programmer.

Now I will turn to your own example of converting a C version of the Blowfish
algorithm to PowerBASIC. By "converting" a C program, you have bought the
architecture of both the language and the author. I suggest here that if
you originally wrote the algorithm in native PowerBASIC and optimised it
to get the best performance, it would not translate directly to C all that
well either.

I am of the view that your solution to optimise the inner loop in assembler
is the correct way to do it. PowerBASIC writes assembler as native code
so you have supplied a pure basic solution to the porting problem.

If you want to make life difficult for C programming comparisons, write a
Boyer Moore search algo in pure PowerBASIC and after you fully optimise
it, pass it over to the C programmer to convert.

Most know that I am not of the current OOP disposition as it is implemented
in most compilers at the moment yet I am of the view that programmers who
want to write code of this type should be able to do so in PowerBASIC if it
can be done in an efficient manner without ruining the current performance
of the PowerBASIC compilers.

My interest in the thread started by Florent was based on his and other
contributors expertise in low level OOP design and what I was interested to
see was if there is a way to implement the minimum necessary to support in
an efficient manner.

Your support for Stephane spamming the forum with Delphi virtues surprised
me some, I sugest that the people who best understand the needs of the
great silent majority is PowerBASIC INC. not the non-contributory spamming
in favour of another company's product that Stephane has continued to do.

I have no doubt that Borland/Inprise have support groups for Delphi users
but I don't see that the PowerBASIC forum should be used to advertise another
company's product. I suggest that the response in the "Delphi & Pascal Users
Group" would be less than positive if someone spammed them about the virtues
of Microsoft VB or VC++ without responding to their answers and views.

My trailing comment on using C inline asm was aimed at making the comparison
direct,

    __asm{
      ; asm code here
         }

    or

      pb code
      .....
      ! asm code here
      .....
      more pb code

will tell you who got their compiler design right, optimising compilers do not
like hand writen assembler where the PowerBASIC compiler manages it fine and
does not mess up the hand written code.

Does the challenge that you issued in reverse assume that hand optimised code
is not acceptable for comparison ? Lets hope not.

Regards,

[email protected]

[This message has been edited by Steve Hutchesson (edited September 25, 2000).]

[B Hall]

Well a quick check of the product descriptions and PB claims that
the DLL compiler is the worlds fastest compiler. And they claim
to outperform VB in a double-precision calculation looping and
in a string array sorting. Then its said that the PB DOS compiler
benchmarks well against C, C++ and Pascal compilers and that the
PB CC is much faster than the DOS compiler.

Okay, everyone here knows that the PB compilers are in the league
of fastest compilers, that they are Basic, and that they create
small-footprint applications.

The astounding thing is CB saying that VB 5 or higher is as fast
as anything. Well, VB does claim a native-code compiler and that
is different information than in the past. (And Delphi says the
same thing.) So I can rationalize it: The VB run-time produces
the GUI and the application code in VB is compiled. Then the run-
time does something like call the compiled application code...(Now
a recent topic had VB as faster at opening files and doing file
operations, but recommended changes to the PB code had other
posters then claiming PB to be much faster than VB for the file
operations.

------------------

[Chris Boss]

Now, don't forget that one aspect of PB being one of the fastest
compilers, has to do with "compiling" speed.

PB (and C) use code that is much closer to the Windows API, so they
need to have all the API declarations. This means that every time
you compile a program, the compiler has to parse a huge include file
of API declarations which takes time. PB is "lightning" fast
in the actual compile process and it simply "flies" through huge
include files.

Just take a look at how big the win32api.inc file is !

PB literately "eats" it up when compiling and your app compiles
nearly "instantaneously".

This is "very" important if your app has a bunch of include files
for a bunch of DLLs needed by your app.

When I make changes to my code and then recompile, make changes
and recompile, again and again, I don't even notice the compile
process. It is just so fast !

I can remember compiling DOS apps with MS PDS 7.1 and just "waiting"
and "waiting" for the compiler to finish and DOS apps didn't have
huge include files to parse.

Oh, and I only use a 200 mhz 686 CPU in my PC. If you are using
a high end PC (500 mhz or higher), then probably PB can compile
faster than you can "blink your eye".



------------------

[Tim Wisseman]

It takes 48 seconds for to compile the current project
I am working on. I have a P200, the compiler is doing 280,000
lines a minute.

Another project that I am working on in VB5, which is a little
smaller in size takes at least 30 minutes to compile.
VB5 uses the C++ compiler c2.exe )

Yeah, PB is a very fast compiler.

Tim

------------------

[B Hall]

Well compiling speed is one of the topics in the product
descriptions. (Borland also claims world's fastest compiler for
their C++.)

But change the topic to application speed and move to the bottom
line. In other words can a large run-time that calls compiled
code be fast?

------------------

[Tim Wisseman]

The most important thing speed wise is not the language at
all it is the programming style and design.

It is possible to right very fast Visual Basic or even Java
programs, if you know what you are doing.

It is very possible to write slow programs using C or PB. I
have seen code that does dumb things. . .

Like this piece of slow code. . .

  Dim b As Byte
  Dim array1(1 to 100000) As byte
  Open "testfile.dat" for binary as #1
     For i = 1 to 100000
        Get #1, i, b
        array1(i) = b
     Next i
  Close #1

   
  '// This is a better way
  '// Just one disk read instead of 100000 reads . . .
  Dim array1(1 to 100000) As byte
  Open "testfile.dat" for binary as #1    
      i1PTR = VARPTR(array1(1))
      sBUFF = STRING$(100000, 0)
      GET #fyig, pt, sBUFF
      POKE$ i1PTR, sBUFF
   Close #1

------------------