Visual Basic v Fortran 3

[EnglishMuffin]

For programs (or parts of programs) that can be written using either, is there really any difference in speed between compiled VB and Fortran ? I know some developers write VB programs and call Fortran routines from them, but is this really necessary ? Is it really just because they have existing code and don't want to re-write it? I realize that there are some things like quad precision that can only be achieved using Fortran compilers.

 

[IRstuff]

From a pure operating code perspective, probably not. VB is probability a bit more integrated with Windows services, so user interfaces and system resource calls are probably slightly better supported.

For math-specific programming, FORTRAN probably still ahs a slight edge, mostly due to math routines that have been tried and trued. But, in many cases, the actual math speed is inconsequential relative to the user interface programming, in which VB excels.

TTFN

 

[EnglishMuffin]

Thanks IRstuff

That's what I thought - I was in a meeting a while ago, in which a developer had asked a lot of people from various industries for input on the program he was going to write, and he said he was going to write it in Visual Basic with the math routines all done in Fortran, and I said why not just use Visual Basic for everything. And everybody jumped on me and said don't be ridiculous, it wouldn't be nearly fast enough. When I got back to my own office, I asked a guy who new a thing or two, and he looked it up somewhere on the microsoft web site - and said, well they are both compiled in native code so there won't be any difference. And there was another developer who wrote a program that I was using - he had written that in VB with Fortran routines - and told me he couldn't get the performance any other way - so I was a bit mystified by it all. I guess I'll take your opinion as being correct unless someone else responds differently!

 

[JBando]

Well, there are some other issues:

Fortran has got hugh - I mean HUGH library routine available. Fortran is ment for heavy duty computation. Furthermore, some the Standard Routine ( if you do any Numerical methods then you may be aware IMSL- International Mathematical and Stat Lib, etc) are not available in VB platform. Furthermore, you are dealing with old code, then they might have historical data accessed as random access files. In fact I have developed Fortran DLL to run from Excel- as the interface is easy.

But given a choice, if it is not hugh coding it is better to convert everything to VB, but you may lad up in some different problem. Keep posted..

Thanks,

Jay

 

[DanTex]

There IS a huge difference between VB and Fortran in how your codes will execute!! VB is flat out a LOT slower than Fortran. I've done a lot of test myself ( often just for fun ). I've yet to see even a simple code in VB outperform a Fortran code. Even character string manipulation will be a lot faster in Fortran than in VB ( kind of interesting since most people only think of Fortran for numerical codes ). The larger your code gets, the more difference you will likely see in execution speed. I've seen Fortran codes that take 10 seconds to execute take over a minute to execute in VB.

As for the information you were given about both languages being "compiled in native code so there won't be any difference"... don't believe that for even a millisecond. The truth couldn't be farther away. VB is one of the slowest languages you will EVER work with ( regardless of application type ). Fortran is likely one of the fastest languages you will ever work with ( especially for numerical work, but also for other stuff ). VB is slow for a couple reasons. 1) Basic in and of itself is not exactly a fast language. 2) VB is made by Microsoft and thus, there is very little ( or none ) attempt by the VB compiler to optimize your executable code for speed.

NOTE: I'm NOT saying that you shouldn't use VB!!!

What it all comes down to is..... what exactly is it that you wish to program????
Speed is really pretty inconsequential if all you have is a short program that will run in less than a second or two. In such a case ( and if I were you ), I would just use whatever language you already know and feel comfortable with. On the other hand, if you are doing something that will take a while to execute or if it has to be executed over and over again ( making execution speed a priortiy ), I would certainly use Fortran, at least for the time-intensive portion of the code.

Your programs GUI is a different story of course. VB is geared towards a Windows style GUI. VB or Delphi are pretty good languages for that kind of thing. And... GUI's can be a royal pain to create ( without bugs that is ). The GUI code is often much larger than your actual "applications" code. You can also do a GUI in Fortran easily enough. I've done several myself. But... VB will have more built-in features than you will find in a Fortran package for this sort of thing.

Writing a GUI in VB or Delphi which calls Fortran DLL's can be a fairly simple way to go if you want to get the best of both worlds.

Dan

http://www.dtware.com

 

[IRstuff]

Was that compiled or interpreted VB?

TTFN

 

[DanTex]

That was compiled VB. I've run test where a friend would write the VB code, compile it and email it to me. I would do the same with a fortran code. Then we'd each test both compiled codes on our respective machines.

I have no doubt that VB could be made to run faster, but... MS apparently doesn't have enough incentive to spend time optimizing their compiler. I correspond regularly with other VB users on the VB Newsgroups. The evidence is quite clear than MS does little to no optimizing of VB. It's rare to find even simple optimizations performed by the VB compiler. Of course... for GUI codes that don't require a lot of intense action "under the hood", that's not generally not a big deal. VB certainly provides decent GUI building capability with a minimum of effort.

Dan

 

[EnglishMuffin]

I suppose one should ask which Fortran you are referring to. Do they vary much ? Which of the current compilers is best and/or reasonably priced ?

 

[DanTex]

Good question. Not all fortran compilers are the same. Their optimization capabilities and abilities to "catch" a users coding bugs are often a "quality of implementation" issue. Also... I'm assuming Fortran 90 or 95 here. Fortran 77 has been effectively obsolete for a decade now. A nice thing though is that you can find free 77 compilers on the web. There is G77 and Portland puts out a good one which is free for non-commercial use. Of course... I highly recommend an F95 compiler for writing new code. Using F77 would be like a C coder using whatever language preceded C or a VB user using version 1.0 ( when current version is around 6.0 ). It just doesn't make much since.

Currently... on the MS Windows platform... I'd say the two most popular compilers are the ones by Lahey and Digital ( note, Digital has undergone serveral company buyout scenarios... ie... HP, Compaq and now Intel ). The Digital compiler and the Intel compiler are different. I think Intel is going to be somehow merging them into one product at some point in the game.

There's also the Nag and Portland compiler which are also supposed to be good. There are others, but... I'm not knowledgable enough on the merits of each. Michael Metcalf keeps an updated list of compilers and add-on tools. You could probably find this simply by doing a search on his name.

The various compilers do vary in both speed and capability. In general though... the major vendors put out a pretty good ( and fast product ). They have to. They need to be able to advertise both reliability and speed in order to successfully sell their compilers. Unlike most languages compilers, a fortran compiler which can't boast fast executables is not going to sell all that well. I use the Lahey compiler myself and in general... I've been extremely happy with it and with the support I get from Lahey when I have a question. When comparing the most recent Digital and Lahey compilers, I think the Digital compiler tends to be slightly faster on the average whereas the Lahey compiler appears to be more reliable ( read bug free, producing correct results and notifying the user of errors in users code ) in the code it produces.

Dan

http://www.dtware.com

 

[IRstuff]

Do all of them come with the same quality math library?

TTFN

 

[DanTex]

Hmmmm. Do you mean "efficiantly executing" math operations or do you mean extra mathematical functions and routines that are included with the compiler that are not actually part of the Fortran standard language ( ie. add-on libraries )?

The major vendors do generally provide good executing math capabilities. Add on products are specific to each vendor though. Speaking merely of Lahey ( because that's what I have )... the Pro version of the compiler comes with the Fujitsu Scientific Subroutine Library which is similar in many ways to the well known IMSL routines.

Dan

 

[IRstuff]

A little of both, I guess.

If the desire is high performance math programming with minimal work, Fortran with a good math library is as good as it gets.

The Fortran DLL call from VB might certainly be a good compromise to get Windows GUI performance.

Anything more would require non-portable custom assembly language routines.

TTFN

 

[jhd99]

And here's me with my Fortran66 (LevelG) manual, & the set of Assembler utilities to enable it to handle text strings - I guess I won't be using these much now . . . . .

Jim

 

[Lalbatros]

Personally I have been calling Fortran code in excel for years (linear and nl programming, linear algrebra, process simulation). It was convenient to re-use Fortran code available from Netlib for example, and the speed was another advantage (specially at the 16-bit time).

However I was more and more interrested in object-orientation and integration in windows. For LP, C++ and OLE/COM made things much more convenient: I could drive the calculations from Excel/VBA through neat object interfaces.

Then I wanted much more but realized that writing COM objects in C++ was not the best way to concentrate on my job (too much boiler-plate code). I switched to Visual J++ and it was a real dream to build COM objects, specially for process simulation. The performances are not as good as C++ or Fortran, but much better than Visual Basic. Object-orientation is so powerful that I could not imagine to develop in Fortran what I am using now in Excel and that I developped in J++. Now Fortran is uninstalled from my computer. Next step may be C#, I tested it and concluded that for my applications C#=J++ , but I watch.

My conclusion: don't use VB when speed matters, try J++ or C# when speed is important (you get objects also), go to C++ if speed is critical and objects are useful, don't use Fortran anymore unless you are forced to (for example: if you don't want to translate page of Fortran).