Which Compiler Now: IFC or CVF?

durisinm · ‎05-29-2003

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

Steven_L_Intel1 · ‎05-29-2003

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

gfthomas8 · ‎06-02-2003

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.

Steven_L_Intel1 · ‎06-03-2003

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

durisinm · ‎06-03-2003

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 · ‎06-03-2003

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#standards
carefully and
http://msdn.microsoft.com/visualc/howtobuy/choosing.aspx

HTH,
Gerry T.

Steven_L_Intel1 · ‎06-03-2003

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

gfthomas8 · ‎06-03-2003

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

durisinm · ‎06-05-2003

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

Steven_L_Intel1 · ‎06-05-2003

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

gfthomas8 · ‎06-05-2003

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

Steven_L_Intel1 · ‎06-05-2003

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

gfthomas8 · ‎06-05-2003

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

Steven_L_Intel1 · ‎06-05-2003

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

gfthomas8 · ‎06-05-2003

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.

Steven_L_Intel1 · ‎06-06-2003

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

gfthomas8 · ‎06-09-2003

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.

kdkeefer · ‎06-09-2003

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 · ‎06-10-2003

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.

Steven_L_Intel1 · ‎06-10-2003

Gerry,

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

Steve

gfthomas8 · ‎06-10-2003

Steve,

Thank you. Consider it over.

Shalom,
Gerry T.