Which Compiler Now: IFC or CVF?

Which Compiler Now: IFC or CVF?

A person at my company needs to upgrade his Fortran compiler for Windows from a very old copy of Microsoft FORTRAN PowerStation 1.0a. If he wants to eventually use the merged Intel Visual Fortran due out later this year, then which is the better buy right now in terms of cost and simplicity: the current IFC or CVF?

We're under tight cost constraints now, so he wants to get the compiler that is the best value. What may be more important, though, is that he doesn't want to learn one IDE now and a completely new IDE and way of doing things once IVF becomes available.

This guy is not the type who will download demo copies of both compilers and try them himself. He's not very good at using the IDE and is counting on me to tutor him on how to, for example, use the debugger, which is what prompted this question in the first place (MPS 1.0a froze every time I tried to show him how to set a breakpoint and then start his program.). I bought the cheap upgrade to IFC for CVF users, but I've used only CVF. I'm waiting for IVF to appear before making the switch.

What say ye?

Mike

26 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Steve Lionel (Intel)'s picture

In this situation, I would recommend IFC. If he doesn't have Visual C++.NET, he'll need to buy that too, but only the Standard Edition (<$100) is required. The price of the combination is the same as CVF and he gets free upgrades for a year and will not have to change IDEs.

Steve

Steve
gfthomas8's picture

One thing wrt .NET std vs pro, both VC++ and Intel C/C++ require .NET pro for optimization. Under .NET std neither VC++ nor Intel C/C++ function as optimizing compilers.

Ciao,
Gerry T.

Steve Lionel (Intel)'s picture

Your post is a bit confusing to me...

Intel Fortran accepts VC++ Standard for the IDE. Intel C++ requires VC++ Pro. It is true that VC++ Standard is a non-optimizing compiler, but that has no effect on Intel C++ (which doesn't support VC++ Standard as I said above.)

Steve

Steve

Now I'm confused. Can you spell it out more specifically when you say that VC++.NET standard is a nonoptimizing compiler? I'm familiar with the difference between building a debug versus a release configuration of a program. Are you guys saying that you can't get the optimizations a release configuration would have in a C/C++ program unless you buy VC++.NET professional?

Mike

gfthomas8's picture

Yes, VC++.NET standard is the minimal requirement for IFC but I'd caution users to look beyond the minimum if they want to use VC++ .NET or ICC for anything important. From MS: Microsoft Visual C++ .NET Standard Edition is available for the hobbyist, student, or beginner programmer.

Intel C++ requires VC++ 7.1 .NET pro to exploit its full optimization features. Intel C++ doesn't come with its own STL (I'm referring to Windows as OS, not Linux), it uses MS's. Try compiling the blitz++ library with Intel C++ and VC++ 7.1 .NET std. There's a ongoing discussion on this in the Intel C++ forum.

Also check
http://www.intel.com/software/products/compilers/cwin/cwindows.htm#stand...
carefully and
http://msdn.microsoft.com/visualc/howtobuy/choosing.aspx

HTH,
Gerry T.

Steve Lionel (Intel)'s picture

Mike, if you buy Visual C++ Standard Edition, the options to enable optimization are disabled. In other words, it's good for learning and playing, but not if you want to produce optimized code. For the Fortran user, though, if the only thing they want MSVC for is the bits that Intel Fortran needs, this doesn't matter.

Gerry, I haven't been following the Intel C++ forum, but since MSVC Pro is a prerequisite, I don't understand why the discussion even comes up.

Steve

Steve
gfthomas8's picture

> Gerry, I haven't been following the Intel C++ forum,
> but since MSVC Pro is a prerequisite, I don't
> understand why the discussion even comes up.
>

Hard as it might seem, there are Intel customers using CVF and/or IFC who might also want to purchase the Intel C++ compiler for Windows. They ought to be encouraged to get the best out of Intel even if that means acquiring necessary but beyond mere sufficient Microsoft bits and pieces.

HTH,
Gerry T.

No optimization with the standard version? That stinks. The CVF approach is much better. The standard version gives you full capabilities, and the professional version gives you all that plus some extras.

Steve has pointed out the other restriction of not being able to have combined language source projects in .NET. Microsoft may think it's taken a step forward with its .NET architecture, but it appears to have taken a step backward with usability features.

Mike

Steve Lionel (Intel)'s picture

Well, in Microsoft's defense, they sell VC++ Standard for less than $100, whereas CVF Standard is $599. The current VC++ Standard Edition is what used to be called "Learning Edition".

Steve

Steve
gfthomas8's picture

> Steve has pointed out the other restriction of not
> being able to have combined language source projects
> in .NET. Microsoft may think it's taken a step
> forward with its .NET architecture, but it appears to
> have taken a step backward with usability features.
>

.NET engenders multilingual interop development if it's exploited to the limits of its design. If there is a 'wall' between languages in .NET, Intel is perfectly capable of scaling it but so far has chosen not to do so and for its own business reasons. .NET is good for Fortran in environments where C/C++ rules since the barrier between languages disappears and divisive religious wars over who is holiest vanishes. Managed .NET can target any comodity processor by generating the appropriate jit instructions via IL for that processor, whether 64-bit Intel or ADM or whatever. Win32's days are numbered and .NET is here to stay.

Ciao,
Gerry T.

Steve Lionel (Intel)'s picture

Sigh...

The barrier MS has erected has nothing to do with .NET managed code. It is that one is not allowed to have a mixed-language project that contains sources from more than one language, which get compiled and built together. This is the way nearly 100% of mixed-language applications are built today.

Yes, theoretically .NET managed code provides a language-neutral environment, but to take advantage of it means significant rework (and relearning), and code that is tied to the Windows platform.

If we knew how to jump the wall for mixed-language applications, we'd be happy to do so.

Steve

Steve
gfthomas8's picture

> Sigh...
>
> The barrier MS has erected has nothing to do with
> .NET managed code.

Who claimed that it was? This is a false inference.

> It is that one is not allowed to
> have a mixed-language project that contains sources
> from more than one language, which get compiled and
> built together. This is the way nearly 100% of
> mixed-language applications are built today.
>

Yawn...I'm more than familiar with mixed-language programming.

> Yes, theoretically .NET managed code provides a
> language-neutral environment, but to take advantage
> of it means significant rework (and relearning), and
> code that is tied to the Windows platform.
>

The Windows platform has served Intel well, and for that matter, Compaq and Digital. Lahey and Salford manage to serve both Windows and Linux without Windows users having to underwrite Linux product development or to be denied full access to their chosen platform. Intel should do likewise and eventually

> If we knew how to jump the wall for mixed-language
> applications, we'd be happy to do so.
>

they will.

Ciao,
Gerry T.

Steve Lionel (Intel)'s picture

Gerry, I'm afraid you've lost me completely. I can't figure out what you're saying in your last post, especially the last two paragraphs.

Perhaps it would help if you'd detail what it is you'd like us to do differently, with pointers as to how this benefits mixed-language native applications.

Steve

Steve
gfthomas8's picture

Steve, the last two paragraphs are lucid, unambiguous, and don't mince words. But here's a more prolix restatement if you really believe that it would help you:

It's convenient for Intel to have a single code base for Linux and Windows since, as you put it, it saves on a "significant rework (and relearning)" required for full .NET support and besides Intel doesn't want to maintain "code that is tied to the Windows platform." The Intel position appears to be that what's good enough for Linux is good enough for Windows even though Windows customers comprise the majority of CVF/IFC (aka Intel Fortran Compiler) users. Intel's cavalier and high-handed treatment of Windows users in failing to provide full .NET support instead of squatting, interloping, and masquerading as an integral part of VS.NET, but with only partial access to all its features, is in contrast to what both Lahey and Salford do for their Windows users. Intel's should follow their competitors lead.

What can Intel do to promote mixed-language development on .NET? You've already answered this in the understatement "Yes, theoretically .NET managed code provides a language-neutral environment." In short,
simply commit to the "significant rework (and relearning)" that .NET requires and for which Intel has had more than ample time. Allow Intel .NET Fortran to fully exploit the framework, the CRTL, .NET object sharing and creation, and, most importantly, IL code generation and round tripping from within VS (here a wizard or two would be handy), this being pivotal to mixed-language .NET development on Windows. Speed is not an issue for most Windows apps so I don't buy the performance penalty excuse.

BTW, I don't give a rat's ass about Linux.

Ciao,
Gerry T.

Steve Lionel (Intel)'s picture

Oh, I think I get it now. You think that the reason Intel isn't offering managed code for Fortran is that we want to keep the same code base as for Linux? No wonder I was confused!

This is so far off-base it's funny. The way the Intel compilers are structured, we could slide a new code-generator in (that's really what you're talking about) easily. We already have two, one for IA-32, a completely different one for Itanium. C++ also has code generators for Xscale and EFI (a specialized firmware interface).

So.. all we would have to do is:

1. Write and test a code generator for MSIL
2. Design and implement new language features to make .NET stuff accessible to the Fortran programmer
3. Reimplement the run-time library to use MSIL instead of direct calls to the Win32 API

Oh, and we need to do all of this at the same time we're trying to complete a MAJOR porting effort of the CVF front-end and libraries to the Intel compiler structure with constrained engineering resources.

And then we need to convince the majority of our customers that they really want larger, slower programs that require the end-user to have installed a "framework" to run.

Yep, it's that pesky Linux least-common denominator!

Now, to take a step backwards. We (CVF) have had a small trickle of users ask about managed code, though when pressed, they admit that all they really want is to be able to use their Fortran code in the .NET environment, but most are not willing to give up performance. Even before our acquisition by Intel, we were working on ways to accomplish that without completely tearing the compiler apart - a "Module Wizard" for .NET. It doesn't look good for that being in the initial Intel Visual Fortran release, but it's still high on our list.

What we haven't seen is a strong business justification for a MSIL Fortran. That Lahey and Salford are doing it doesn't mean anything if those products aren't successful - and it's far from clear to me that they can be. Lahey has been in beta with theirs for a LONG time - it's a really hard job.

I am not saying that an Intel Fortran for .NET is a bad idea. I keep bringing it up to management as something we have had requests for - they tend to look at me as if I had just landed from Mars. But I do know there is interest in MSIL inside Intel, so the first hurdle would be to convince management that enough Fortran customers would buy and use it to make the investment worthwhile.

In any event, nothing is going to happen this year. But we are starting our planning for the follow-on release, and I had already listed MSIL support as one of the things people have asked about. That will at least get it on the radar screen.

I wish we had infinite resources to do every cool thing that came along, but we don't. We have to pick and choose, and Intel's focus is on the best run-time performance along with industry leading quality and compatibility (read, CVF). I'm not convinced that Fortran .NET support would be anything other than a niche market, but I'll admit to being astonished at what people have used CVF for. .NET itself is struggling, according to all industry reports I have read, but may become important in the future. I think our efforts are better spent elsewhere - for now.

Steve

Steve
gfthomas8's picture

Thank you for the apologetics for inertial inaction, replete with the weak defense of sarcasm, illogic, fancied mind reading, technical misconceptions, whining, excuses, and a doomsayer?s conviction that competitors who disagree are destined to fail, all founded on that shakiest of bases, the overly misused ?we don?t have enough resources? anthem.

Just as while spinning for Digital and Compaq you were quick to remind all that IFC was a mere add in to VS 6 in contrast to CVF?s full integration, now we?re to swallow the claim that the future combined Intel Fortran compiler will be fine as an add in to VS.NET. Yes, Intel Fortran will be to Windows what the 8-track tape is to audio, an anachronistic throw back to the future. Of what only time will tell.

Perhaps when Intel gets around to releasing the final maintenance update to CVF 6.6 it could issue a list of known bugs in the soon to be unsupported compiler so users can be aware of them until they settle on a replacement Fortran compiler. In the interim, a Letterman-like ?10 top reasons why you should upgrade to the not-quite-ready-for-runtime-VS.NET Intel Fortran? might make a useful article to for a long overdue newsletter.

Ciao,
Gerry T.

Hello Gerry,
I love debate and am sincerely interested in the future of Fortran for PC's, regardless of the supplier. However,
your last message comes close to name calling. Intel will do whatever makes the most business sense to it, i.e maximize the amount of software sales at a reasonable development cost. If they make a mistake, there will be an excellent business opportunity for you.
Warm regards,
Keith

gfthomas8's picture

Keith,

Thanks you for your comments re marketing practices for Fortran compilers. I agree.

No Intel customer making fair comment on this forum should have to tolerate scarcastic diatribes untempered by rule 47 herein

http://www.buchanan.org/h-189.html

as official Intel policy.

Ciao,
Gerry T.

Steve Lionel (Intel)'s picture

Gerry,

I'm sorry if you read any of my replies as sarcasm - I can assure you that none was intended.

Steve

Steve
gfthomas8's picture

Steve,

Thank you. Consider it over.

Shalom,
Gerry T.

Community Admin's picture

Hmmm. It appears that Gerry is a fan of .NET, and is quite annoyed that Intel have no plans to produce FORTRAN MSIL. Fair enough. However, having a go because Intel isn't doing what Gerry wants is out of line. Steve made it abundantly clear that should enough customers request it, FORTRAN MSIL etc. would be in the pipeline. He also made it clear that this hasn't happened.

From my point of view, I'd have to say that I'd side with the Intel. Despite much touting, I think .NET still has to prove itself. Yes, you can do some neat things with it, yes it makes somethings easier, but when you run into significant problems with it on the very first thing you try and you find that its famed 'management' is not quite as clever as it claims to be...well I can understand Intel's reluctance.

As far as I'm concerned MS has no defence for disallowing mixed language projects in .NET, or for making third party compiler integration more difficult. If you can do it in separate projects, you can do it in a single project. MS is making us jump hoops for the sake of it.

OK, I'm an engineer doing programming, so don't really care about MSIL, or what environment or language I use, I have no particular beef with MS - I make my living with their products, but like most users (surely!) I just want a tool that works and is easy to use.

.NET may be the future, that doesn't mean it's a better future.

Dan

gfthomas8's picture

If you look here

http://developer.intel.com/technology/itj/2003/volume07issue01/index.htm

and

http://www.intel.com/cd/ids/developer/asmo-na/eng/technologies/mrte/index.htm

you may conclude that that Intel doesn't share your pessimism on .NET. Your take on its presumed demise is reminiscent of those who in the past swore that commodity 64-bit addressable processors would never see the light of day and that Alpha's would reign forever. Change happens.

BTW, I personally dislike .NET but I'm getting the best out of it. Of course, YMMV.

Read for yourself the great aeronautical engineer Theodor Von Karman's response to the 'OK, I'm an engineer...' line in

W R Sears, ?Von Karman : fluid dynamics and other things,? Physics Today 39 (1986), 34-39.

Ciao,
Gerry T.

Message Edited by intel.software.network.support on 12-09-2005 01:49 PM

Community Admin's picture

Gerry,

I don't think .NET is heading for any kind of 'demise', its here and its here to stay (just try finding any 'new' help from MS on older technologies!). The fact is, I'll be writing and maintaining C++/FORTRAN for the forseeable future, so hopefully by the time I get to .NET if will be up a few versions so I can avoid the difficulties my colleagues are having with it.

(Judging by the swearing, blaspheming and general incredulity at official MS 'workarounds' (bodging), that regularly emanates from our .NET guys, it still has some issues).

I couldn't get the Von Karman thing...can't get to the PHysics Today site for some reason. :(

gfthomas8's picture

Dan,

Sorry if I misunderstood, I somehow thought you were using .NET. Your colleagues are quite right about it, especially .NET 2002; 2003 is a lot better, especially VC++ with it being more standard compliant, having the STL, managed/unmanaged code, Windows Forms, etc.

'bodging', what a neat word, is it dialect or what's its origin? Destined for OED I bet.

Physics Today is often only kept for several years by most libraries, even AIP's online, but I'm sure you can get it from one of the Royal Charter libs. I read it when it circulated and noted the reference but I don't currently have it.

Ciao,
Gerry T.

Community Admin's picture

Gerry,

Probably me misleading you - I've dabbled with .NET in a kind of 'should we upgrade now' fashion (not yet being the outcome), but other colleagues having to write web-services etc. have already upgraded. They are still on 2002 I think - but do show us neat stuff like writing a web service in 5 mins, extensible GUIs via assembly DLLs etc., and complain about it not releasing references, and its obscure and basic documentation (along the lines of 'AnyOldFunction - this functions performs AnyOldFunction' d'oh!).

Bodging? I don't think its dialect, quite common in the UK, perhaps more so in northern England. To do a 'bodge job' or 'to bodge' - pretty much akin to US kludge/kludging. God knows what its origin is! probably from botch
see http://cgi.peak.org/~jeremy/retort.cgi?British=bodge

Dan

Login to leave a comment.