Which language is faster?

[Dr Walt Fair PE]

Some day I'll have to tell you how I brought the BCS Cray system to its knees back in the late 70's or early 80's ...

CQ de W5ALT

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

[Dr Walt Fair PE]

Thanks Max. I agree. To clarify, I've been coding engineering and numerical apps for over 40 years and all my current stuff is .NET, mostly C#. I also use a double handful of other languages as needed, including Javascript and PHP. The question is concerning a class I have to take towards my engineering PhD, because I don't have graduate credit for numerical methods. :)

CQ de W5ALT

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

[Dr Walt Fair PE]

Thanks for the info. I'm not enthused by BASIC, but I've used it fairly extensively, including old TurboBasic. I'll check into PowerBasic.

CQ de W5ALT

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

[Bruce Patin]

I used FORTRAN in the 70's for a numerical analysis course, and have used other compiled languages since. I have also coded in both mainframe and micro assembler languages. From what I remember, FORTRAN does have at least one advantage for numerical analysis: when you declare your numeric variables, you can exactly specify the precision of the number, and can depend on being able to correctly state the number of significant digits of your calculations. I also know that when you specify the precision of the number, this is directly translated into mainframe machine code instructions especially tailored to the precision you specify, making it very efficient. On non-mainframe computers, this may not be the case. In C/C++ and Pascal, you have to largely depend on the compiler and platform, other than simply specifying int, long, etc., and may get slightly different results depending on which you use. So, I would recommend FORTRAN for numerical analysis, unless you think that future jobs will be requiring you to do that kind of work in a different language, then use that. Regarding assembler, even with compiler optimizations, direct coding in assembler can be much more efficient, but I would never recommend that to anyone, unless you plan on programming micro-controllers where speed is a top requirement.

[ely_bob]

I think this is the Key.. If you look at what constitutes "best practices" in Object oriented languages and what you need to do to get those same languages to "run fast" is break most of the "best practices" because of the way the compiler MUST read the origional code, you basically shoot yourself in the foot... and so when we attempt to compare "Good Code" to "Fast Code" we rarely find a Venn area of overlap... take the number of people who know that switch is faster then if ..else if...else if.. and the prevelance of Properties in all code.... as well as the "allowed" overhad to run two equivelant apps where WPF over WinForms is used on a client machine, then talk to me about optimization... :doh: .. ohh and fortran uses GoTo.... :-\

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

[Dr Walt Fair PE]

Yes, I agree, and for th class I will probably use FORTRAN if the profs want me to and if I can get a reasonable compiler. Most of my current work is in C#, though.

CQ de W5ALT

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

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