Which language is faster?

[Chris Boss]

PowerBasic, IMO is one of the software industries best kept secrets. Most online computer and developer magazines rarely ever mention it. I have been using Powerbasic for nearly 10 years now and I can write code which will run circles around stuff written by C++ or VB# programmers. I write a good bit of code which requires optimal speed, such as things like 2D animation, 3D OpenGL animation, Image Filters, etc. I write a lot of stuff that deals with Graphics (ie. customizing controls via Ownerdraw, my own Graphics controls, etc.) and speed is critical. I can write applications or DLL's which rival the speed of any language and still write stuff that will fit on a Floppy Disk or will run on Legacy PC's like Windows 95/98 (with CPU's below 500 mhz). Now my experience as a Windows API programmer gives me some advantages, but PowerBasic allows me to tap into the Windows API with an extremely fast compiler.

[Mark AJA]

Machine code is the fastest to run but the slowest and hardest to write. I stoped writing machine code when I moved from RISC to Windows 95.

[Mark AJA]

BASIC is not fast. With BBC Basic you could include machine code in your BASIC program to speed up your application.

[Dwayne J Baldwin]

Ask yourself the same subject with human languages instead of computer languages. Compared to English, Chinese sounds fast and French is backwards. Spanish and Italian are close as are Russian and Ukrainian. Language in any book (compiled) is faster than real time translation (interpreted). Working in human terms (base 10) involves translation from electronic calculations (base 2 or binary). Numeric computations are subject to formulae and translated results are very subjective. Your code will probably reuse math functions from libraries. Unless one writes the entire codebase from scratch, they are scaffolding on other interpretations, perhaps in other languages which may or may not affect overall speed. Which human language crunches numbers fastest and which human crunches numbers fastest are two very different things. You really need to specify the task to quantify any performance. Lastly, Fortran may be an excellent opportunity for personal understanding, but it is not as easy to implement and will hardly pay your bills any faster.

Dwayne J. Baldwin

[Chris Boss]

Quote: "BASIC is not fast" Thats what you may have been told, but I assure you Powerbasic is not only fast, but it can stand its own with most any other compiler, even C. The misnomer that Basic is slow and a poor language dates back to the time when many basics were interpreted. A compiled Basic can be just as fast and as any other language and there is nothing inherent to the Basic language which would make it hard to compile to a fast executable. PowerBasic (the company) are experts at optimizing machine code generated by the compiler. For example let's just take a look at a simple bit of code:

 REGISTER x AS LONG, y AS LONG, z AS LONG
 LOCAL t AS DOUBLE
 LOCAL i AS LONG
 x = 5
 y = 3
 t = TIMER
 FOR i = 1 TO 10000000
      IF x > 1000000 THEN x=5
      x = x \* y
 NEXT
 t = TIMER - t
 MSGBOX FORMAT$(t,".0000")

This simple FOR NEXT loop executes 10 million times, doing a simple multiplication calculation. Now the PowerBasic compiler does not cheat by generating short cuts in code it may assume does nothing, like other compilers do (others do that just for benchmarking to make their compiler look good). This FOR NEXT loop is executing every iteration. Now how fast does 10 million iterations take on a common Desktop running Windows XP with a mass produced 2.5 ghz Celeron CPU (no cores or multiple CPU's) ? .094 seconds ! Yes, the PowerBasic compiler is generate code for the above code which executes 10 million iterations in less than 1/10th a second. Now I don't think that is slow. Sure, some compiler out there may beat that, but PowerBasic can hold its own quite well. Now add to this the richness of the language so you can write better code (to make it faster) and the ability to add inline assembler when you want to and you have a language which can create amazingly fast executables. I should know. I have been using it commercially writing tools for programmers for about 10 years.

[ghle]

ely_bob wrote:

.. ohh and fortran uses GoTo....

Which is what makes it fast. No loading up the stack/heap and saving registers for performing those nasty subroutines. :laugh:

Gary

[ely_bob]

Like I said, bad code practices, good performance...... But I figured it would get to at least someone on here.... :laugh: :-D :laugh: :-D :laugh: :-D :laugh: :-D

I'd blame it on the Brain farts.. But let's be honest, it really is more like a Methane factory between my ears some days then it is anything else...
-----
"The conversations he was having with himself were becoming ominous."-.. On the radio...

[yoni at jefco]

FYI - Same code in C# returns 0 MS.

       int   x = 1;
       int y = 1;
       DateTime t = DateTime.Now;
        for (int i = 0; i < 10000000; i++)
		{
	        x = x \* y	    ;
		}
         double d =  DateTime.Now.Subtract( t).TotalMilliseconds;
         MessageBox.Show(d.ToString());

I have to change the loop count to 100 Million to get a time of 31millieconds back. (I was actually expecting the c# compiler to omit the entire loop. I'm surprised that it didn't) YS

[patbob]

Walt Fair, Jr. wrote:

So, aside from interpreted languages, is there a real case to be made for FORTRAN being faster than other compiled languages on number crunching?

No. What matters is the compiled machine code, not the source code used to generate it. C/C++ are easily every bit as good as controlling that as Fortran or Pascal. If you want real performance, you code the innermost loop so it fits entirely in the instruction cache of the CPU and minimizes data fetching and saving. By definition, you can't achieve that with an interpreted language, which is why they are not good choices for ultimate speed. You won't get extra points for implementing the assignments in the professor's favoriate language, but you will loose points for not getting the assignment done. Use whatever natively-compiling language you're happiest with.

patbob

[Chris Boss]

I posted the example code to demonstrate the Powerbasic compiler is fast, not to use it as a benchmark to compare it to another compiler. The problem with such comparisons is that some compilers use shortcuts to speed up such simple loops to make the compiler look faster than it really is. PowerBasic never does this. Without being able to examine using a disassembler to see what code the compiler is actually generating it is difficult to tell whether it is accurate. Also one has to be careful in the objects used for such small timing, to make sure they are accurate done to the millisecond level. The only way to truly compare two language is to make sure the code is not effected by any "tricks" of a compiler and the timer must be a precision timer to be completely accurate. Also you have to run such a benchmark example, using both languages on the exact same computer. There is a big difference for example between my 7 year old 2.5 ghz Intel Celeron CPU (and even the RAM speed) compared to many of the much faster CPU's likely found in the average programmers PC. If you don't take into consideration such factors you can't make any comparisons.

modified on Monday, January 10, 2011 7:46 PM

[Gary R Wheeler]

The examples you cite meet my "small number of cases" criteria. I would imagine the algorithms involved have been finely tuned. The only remaining avenue to improve performance is to better align the algorithm with the hardware ro take maximum advantage. Those are cases where the benefit of assembly language optimization exceed the cost. My argument is that, most of the time, that's not true. Assembly language optimization increases the maintenance cost of that portion of the application by an order of magnitude or more. Development is slow and painful. Faults in the assembly language implementation often crash the application, sometimes the entire system, with no trail of bread crumbs to follow, making debugging difficult. If you are using special processor instructions (often the sole justification for the whole thing), you are subject to errata in the implementation and the documentation. You often need to know hardware details that are proprietary. With the CISC architectures, I'm also doubtful a human programmer could adequately map a complex algorithm to an optimal configuration of pipelines, cache sizes, and so on, taking into account branch predictor behavior and the like. I've done that sort of thing in the past with fairly simple processes, and the results weren't awe-inspiring considering the amount of work that went into it.

Software Zen: delete this;
Fold With Us![^]

[ghle]

ely_bob wrote:

Like I said, bad code practices, good performance......

Forgot self-modifying code. Now that was efficient! And fast. And tight. Not such a good practice, however. :-O :thumbsup:

Gary

[James Lonero]

Now you know why he's in a university and not doing real programming (software engineering included).

[Stonkie]

I've been reading/hearing about GPU based calculation a lot recently. Apparently, matrices can be sent to the GPU and processed in batch to greatly optimize the calculation. Maybe that would be worth looking into?

[PIEBALDconsult]

Oh, then maybe BASIC-Plus is the language to use.

[PIEBALDconsult]

Well, I did a little test. I put the books I have for various languages* on the floor to have a race -- they were all equally fast. * Ada, VAX C, VAX 11 Assembly, C#, Perl, Javascript, BASIC-Plus, Turbo BASIC, 8086 Assembly. I don't know what I did with my Fortran and COBOL books from college.

[Dr Walt Fair PE]

Well, for human languages, it depends on what you want to say. For example I can say some things faster in English (my native language) and other things are better and easier said in Spanish (also fluent). In human languages, for the most part, you can say anything in any language, but the ones you are most fluent in generally are faster and easier -- and that has little to do with the language itself. I suspect the same holds for programming languages to a large extent. I wouldn't say that any language is faster or better or worse in general, although the implementations of compilers and familiarity with libraries, etc. may make a big difference.

CQ de W5ALT

Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software

[Dr Walt Fair PE]

Yes, that's why specifically said "aside from interpreted languages," however, Forth can come pretty close to assembly. On the other hand, I've written Forth systems in C and assembly and assemblers in Pascal, so ... Make no mistake, I will get the assignments done (SND CODEZ PLZ!!!!) in whatever language makes sense and I'm not afraid to brush up on C or FORTRAN if need be.

CQ de W5ALT

Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software

[Dr Walt Fair PE]

Hah!! I never thought of trying that, so I conducted an experiment. I put my ooks next to each other and the old FORTRAN book fell off the stack and slid downhill fastest. Ergo, in at least one uncontrolled experiment, FORTRAN was fasterest!

CQ de W5ALT

Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software

[SeattleC]

I'll try to answer the original question. First off, there is no answer that is always going to be right. On a 10-line program, assembler is likely to be faster if you know what you're doing. On a 10,000 line program, it is possible that assembler will be faster, but nobody knows because the assembler guy is still writing and debugging. Second off, as previously noted, using the right algorithm is more important than using the right language. You can code a bubble-sort in blazingly optimal assembler, and a merge-sort written in visual basic will eat its lunch on a dataset of any size. (This was an actual experience of mine :-) Third, it is amazing to me the number of people who base their assertion that assembler is better on the output of the compiler when optimization is turned off. The assembler output of optimized builds of C++ programs looks pretty gosh-darned good. Fourth, some language features interfere with optimization. In C++, references and pointers can interfere with some optimizations, so a program with pointers may generate less-good code than a similar program written with plain old subscripted arrays. The optimizer basically turns your subscripted array references into pointers, but the optimizer knows that the optimizer-generated pointed-to locations are not aliassed to other locations, which it doesn't usually know when you use pointers. What this all means is that a FORTRAN program may generate better code than a C++ program that does the same thing in a different way. Fifth, you mustn't confuse the language with its implementation. Java programs usually run an order of magnitude slower than similar C++ programs. That's because most java implementations use a byte-code interpreter that is never gonna be competitive with compiled assembly language. You can get java-to-assembler compilers. They run numerical code pretty darn fast. There are JIT java compilers that offer intermediate levels of performance. Java string processing that uses dynamic memory allocation is always always always gonna be slower than a C implementation using static buffers. So, what are we left with? If you limit yourself to FORTRAN-ish features, any statically compiled language will generate about the same code for an optimized build, and it will look pretty good compared against assembler. That's because the same optimizations are possible, and many compilers (visual studio, gcc) share backends among their statically compiled languages. Compare a compiled language like C++ against an interpreted lang