Plans for IVF producing .net code ?

[tonyjay68]

Firstly

Is there a document anywhere describing intels policy for IVF and .net code (i.e. IL)? (and/or a timesclale)

Our long term aim is to support both Windows flavours of 64 bit (as well as 32 bit) so .net seems a good option.

It appears that there is at least one Fortran .net compiler up and running, but my web search onIVF and .netkeep getting too many irrelevant hits about the .net studio where I mean about producing the Intermediate language.

Secondly

Is there any document describing whether IVF will support AMD 64, orcross compile for AMD(I guess this is a daft question, but I can't find any thing saying it wont)

Obviously these two questions are related. If our 64 bit future is not with IVF there appears to be another current solution already available on the market from Salford which will soon be 64 bit (I am still a CVF user yet to upgrade all our CVF to intel licenses)

Tony

[Steven_L_Intel1]

Intel has no current plans to support MSIL in its Fortran compiler. There are two such products I know of, Salford and Lahey. It is not clear to me what benefit you see from shifting to .NET interpreted code - it doesn't gain you any portability to 64-bit platforms over a compiled code 32-bit executable, and is likely to be a lot slower (and require the end user to install the .NET Framework, which narrows the set of Windows variants the code can run on.)

Intel has not made public any plans to offer a compiler for non-Intel architectures. However, Intel announced yesterday its intention to offer 32-bit processors with 64-bit extensions, compatible with those of AMD, which should give you something to think about...

[g_f_thomas]

Three points:

1. When you first run a .NET app, the MSIL compiles: it's at that point that you start making an assessment of how fast or slow the _compiled_ code runs.

2. Use the ILDASM app to disassemble the MSIL and tweak it for the optimization you find it lacks.

There are several good books one can look at to learn about MSIL:
(i) .NET IL ASSEMBLER by S. Lidin (MS Press)
(ii) .NET CLR by J. Gough (Prentice Hall)
(iii) Essential .NET, vol1 by Don Box (Addison Wesley).

You can come a lot closer to matching so called native code than you'll be led to believe by hearsay. Try and make your own judgment. Maybe some group at Intel will concoct an IL generator and pass it on to the Fortran folks for use in IVF.

3. The .NET Framework will be incorporated into the next version of Windows 32/64 so there'll be no need to download it.

If you're stuck on Windows as OS, the sooner the better you move beyond retro console and QuickWin apps and make the best of .NET for it's here to stay.

HTH,
Gerry T.

[Steven_L_Intel1]

What do console and QuickWin apps have to do with anything? It's straightforward to create a full Windows UI app in compiled Fortran.

[g_f_thomas]

Console and QuickWin apps appeal to those who know little about Windows programming and could care less. There's always Linux. Sure it's hardly rocket science to create a GUI in Fortran but it's even easier using .NET Forms. And how does an IVF-generated Window/Form host COM objects? And how does one create a COM object in IVF? COM is integral to Fortran Windows apps if you're not prepared to use the .NET CLR. Perhaps when you get around to supplying some illustrative samples with IVF you can include these two suggestions.


Ciao,
Gerry T.

[Steven_L_Intel1]

Gerry,

It seems that you want somewhat more than "producing .NET code". Just so that I understand, what additional features would you expect in such a product?

[tonyjay68]

Steve wrote:

> It is not clear to me what benefit you see from shifting to .NET interpreted >code - it doesn't gain you any portability to 64-bit platforms over a compiled >code 32-bit executable, and is likely to be a lot slower

The only reason I need 64 bit is toaddress >2gb ofmemortI have no need of any larger data types.

I do not understand what "it doesn't gain you any portability to 64-bit platforms over a compiled code 32-bit executable" means can you elaborate. My assumption is that I do get portability.

Our normal code runs without any changes on a 64 bit hp unix (the only way our cutsomer can currently run our code 64 bit)

I am unable to predict what architecture will be the one which our customers want to buy (AMD/ itanium). It does seem that AMD 64 is available in the shops - so .NET is an attractive option.

Ifi could produce a 64 bit .NET, I would not need multiple platforms on my desk producing mulitple solutions with multiple compilers.

as far as speed - going to 64 bititanium is going to slow down executionspeed I assume any way, I can buy a 3.3GHz pc at the moment. My impression is that the itanium will notbe any where near this speed.

>Intel has not made public any plans to offer a compiler for non-Intel >architectures. However, Intel announced yesterday its intention to offer 32->bit processors with 64-bit extensions, compatible with those of AMD, which >should give you something to think about...

Have you a link to the announcement ?

Cheers

Tony

[TimP]

http://developer.intel.com/technology/64bitextensions/faq.htm

has the marketing line on the x86_64 architecture.

Among theattractions is the opportunity to get good performance on 32-bit native compiled applications, surely exceeding what could be done with IL.

Your questions have run somewhat far afield from Fortran. As Steve pointed out, itmight well be thatan application built to run IL on .NET across a variety of platforms might be limited to 4GB address space on all platforms.Short of a commitment from Microsoft to support more of what you want, I wouldn't count on it.

[Steven_L_Intel1]

Tony,

I am a bit confused - there is no 64-bit .NET environment, at least not in the near term. Does .NET provide built-in support for dynamically sizing data past the 4GB boundary? (I don't know.)

You can get information on Intel's announced 64-bit extension technology here.

[g_f_thomas]

Here's the skinny on 64-bit .NET:

http://www.osnews.com/story.php?news_id=5860

Perhaps it'll sail on Itanium's maiden voyage.

Ciao,
Gerry T.

[g_f_thomas]

Steve, you misconstrue. Windows apps tend to belong to one of three eras:

1. Early
Petzold boiler plate code, Win API, Dialog Editor, Console, QuickWin, no COM containment, no COM creation, COM invoke (somewhat),...
2. Middle
API, COM creation (somewhat), COM interop (somewhat), no COM containment, ...
3. Late
CLR, IL, API, COM interop,...

In its current incarnation IVF is of Early vintage while CVF falls in the Middle. At least IVF should maintain CVF's capabilities and more: full COM containment and creation. At best IVF should aim to provide full .NET capabilities with a concomitant de-emphasis on COM, in addition to native code. Intel is well capable of writing its own IL generator for IVF.

I am amused that in the release notes for IVF 8 the number of CVF features absent in IVF far exceeds its new features. IVF has to appeal to CVF Windows customers. If I had a dedicated cluster at my disposal I'd make sure it didn't have Windows as OS and the OpenMP/MPI capabilities of IFC for Linux would be terrific. Alas, Windows OS lends itself better to grid/distributed computing no thanks to OpenMP and therein lies the appeal of .NET.

BTW, when is IVF Pro due for release? Will there be an IMSL 5 upgrade path?

Ciao,
Gerry T.

[Steven_L_Intel1]

The Pro edition is scheduled for the end of March and there will be upgrades available.

[tonyjay68]

As far as no 64 bit .net in the 'near term'

http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx

implies that its a 2004 product

I'm not sure what 2004 means however.

Tony

[Intel_C_Intel]

There's an interesting article in this month'sMSDN mag (http://msdn.microsoft.com/msdnmag/issues/04/03/ScientificC/default.aspx ) on using MSIL for scientific applications. On some benchmarks the performance of managed vs. unmanaged code is comparable. On others there's a 2-1 advantaged in using native code. There seems to be a lot of potential for improvement in how the .Net runtime is tuned for scientific apps though, so this performance difference might lessen over time.

John

[TimP]

According to the text, the comparisons are between optimized IL and an unspecifiednon-optimizing C compiler. I certainly hope that "unmanaged" Fortran could beat both of those.