No announcement yet.

PowerBASIC versus C & C++

  • Filter
  • Time
  • Show
Clear All
new posts

  • PowerBASIC versus C & C++

    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.



  • #2
    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.




    • #3

      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

      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

      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 code here

      You may end up with something worth comparing.


      [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.

      hutch at movsd dot com
      The MASM Forum - SLL Modules and PB Libraries


      • #4
        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.


        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
        P.S.S Im not sure what you're trying to prove with the asm code

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


        • #5
          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).





          • #6
            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).]
            Chris Boss
            Computer Workshop
            Developer of "EZGUI"


            • #7
              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?



              • #8

                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.



                • #9
                  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.

                  Chris Boss
                  Computer Workshop
                  Developer of "EZGUI"


                  • #10

                    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.
           | Slam DBMS | PrpT Control | Other Downloads | Contact Me


                    • #11
                      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?



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


                      • #12
                        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.





                        • #13
                          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.




                          • #14
                            ...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.



                            • #15

                              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

                                    ; asm code here
                                    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.


                              [email protected]

                              [This message has been edited by Steve Hutchesson (edited September 25, 2000).]
                              hutch at movsd dot com
                              The MASM Forum - SLL Modules and PB Libraries



                              • #16
                                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



                                • #17
                                  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 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".

                                  Chris Boss
                                  Computer Workshop
                                  Developer of "EZGUI"


                                  • #18
                                    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.




                                    • #19
                                      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?



                                      • #20
                                        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