View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Mon Apr 28, 2008 11:50 am Post subject: Fortran for .NET |
|
|
General fortran question. Do anyone here find the Fortran for .NET has great value for them which was worth of additional speed decrease (how about compilation speed too) ? Give me good reasons to switch to Fortran for .NET, or better, after a half a decade, show me real examples of someone gained from that.
Last edited by DanRRight on Tue Apr 29, 2008 12:09 am; edited 1 time in total |
|
Back to top |
|
|
Andrew
Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany
|
Posted: Mon Apr 28, 2008 3:49 pm Post subject: |
|
|
The main key here is language interoperablity. If you have need to interact with libraries written in .NET then essentially you need to use Fortran in .NET - you may have to integrate with a front-end written in C# for example, or a company may have provided a pre-compiled library written in any other .NET language. There are tricks to use .NET libraries from Win32 code (and vice versa, often with pretty nasty ways to do it) but using FTN95 with .NET gives you the means to do it natively. .NET also gives you access to a wide range of class libraries that have a good deal of functionality that may be required.
If you are writing applications that deal with Win32 only then you likely have little need to use .NET. It all depends on what you need to use your Fortran for and what else you have to interact with, there may be many reasons for choosing it, or of course many reasons for not. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Thu May 01, 2008 9:17 am Post subject: |
|
|
So, no specific examples that someone gained from .NET and fortran? Did that increase the interest of users at least by 1%?
Well, here are the questions of different sort. I am still using older (like 5 years old) win32 compiler/debugger due to absence of any incentive to switch to .NET (and Salford never actively stimulated to do that. At least I did not see any appealing examples so far).
Questions which probably affects 99% of users are: during the development of fortran for .NET have you guys found (what is usually happen) and fixed numerous problems with stability of Win32 debugger and compiler?
I am moving right now some large unix fortran 77/90 code to windows Salford fortran and each and evey error in I/O (open/close/ write) of the code ends up in sdbg crash (i.e. it starts ok, but when error occurs, all source text windows of subprograms disappear - which is just total nonsense not fixed for 15-20 years which makes many people frustrated with compiler - and the only I see is one assembler window which is useful probably for 0.00001% of users, basically none, i.e. the debugger never stops at the wrong line, wraps all windows...same with recent ftn95pe... ). Were at least these problems fixed when you debug the programs using MS Dev Studio? This alone will convince me to switch to .NET |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Fri May 02, 2008 7:36 am Post subject: |
|
|
Dan,
wrt "each and evey error in I/O (open/close/ write)" Why not fix your error management for these, using a standard fortran approach. The use of "IOSTAT=" and "ERR=" provides a very clean way of manageing these errors. F95 has improved things a lot in this area.
I don't think it's the fault of SDBG.
John C |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Fri May 02, 2008 9:45 am Post subject: |
|
|
Wanna try to debug it?
The code has extensive use of all of these features. But it is large, there is almost no OPEN/CLOSE units left till unit=100 .
And it works on 5-6 different unix platforms for decades. It was also ported, as I've heard, to Windows Lahey fortran.
You've probably forgot that Salford is the only compiler which is extremely sensitive to all sorts of IO parameters. Like use of units 1 to 6 and list directed (i.e. write(*,*) ). I also have sporadic BACKSPACE problem for decades in my own code I can not find the reason of.
I do not know what for this was invented, but as you know, that the compiler has all sorts of substitutions for OPEN, WRITE and READ - like OPENR, READW and so on. Was this done to avoid all that sorts of conflicts ? I did forget already, let the developers remind us. But this is something other compilers mostly do not have problems with.
May be someone really wants to try do debug the code?
It is not mine, which makes all of us equal.
It would be good school and great testbed for developers for improvement of Win32 debugger unless they are well familiar with all this and besides the Dev Studio version of FTN95 already solved that sorts of bugs
Last edited by DanRRight on Fri May 02, 2008 10:12 am; edited 3 times in total |
|
Back to top |
|
|
DrTip
Joined: 01 Aug 2006 Posts: 74 Location: Manchester
|
Posted: Fri May 02, 2008 9:58 am Post subject: |
|
|
Also
If I am reading your email correct
the win32 debugger sdbg has been upgraded a couple of times I think in the time scales you are talking about not just the addition of .NET compiler.
and to answer you first question
I use .NET all the time mostly because I have to interact with databases and the .NET libraries are brilliant for this ( no nasty windows message handles etc to faff with just about 6 lines of code and your done).
Talking to Excel is also nicely supported which is basically a requirement in my place of work.
The run time hit you talk of is pretty small and I don't notice it.
It only happens the first time a certain bit of code executes because of the JIT compilation and if you really want there are tools that create native executables from .NET assemblies.
I must say that in my place of work although we do numerics, there is far more pressure to get something working that to get it running quickly.
Development time should be at a minimum. and the run time is of a lesser importance. Shaving an hour of a 24 hour run would be deemed a waste of time. especially if it had taken a week to achieve.
The .NET libraries are a like sweetshop fort his environment. Bascially nealry everything has been done for you!
Carl |
|
Back to top |
|
|
Andrew
Joined: 09 Sep 2004 Posts: 232 Location: Frankfurt, Germany
|
Posted: Sat May 03, 2008 7:14 pm Post subject: |
|
|
It seems to me that you are not just referring to .NET but to Visual Studio. FTN95 has support inside Visual Studio for both Win32 and .NET programming (and debugging for both variants). Have you tried your code inside Visual Studio? If you want to see what kind of milage you get with it then it might be worth you downloading a trial of Visual Studio - you can get a 3 month trial from:
http://msdn.microsoft.com/en-gb/vs2008/products/cc268305.aspx
FTN95 can be reinstalled and will integrate into Visual Studio and you can give it all a whirl.[/url] |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Fri May 16, 2008 12:50 pm Post subject: |
|
|
I have to admit, that recent builds of sdbg debugger are darn good and stable, no crashes at all, no units conflicts or that sorts of things which drived me nuts before. Good job, Salford/Silverfrost |
|
Back to top |
|
|
|