We’re working on moving to VC 2003 from vc6 for mustang. The ‘free toolkit’ from MS is not usable, as it’s missing some important and widely used libraries, not available for free.
Anyway, keep an eye on mustang builds (https://mustang.dev.java.net/).
[quote]The ‘free toolkit’ from MS is not usable, as it’s missing some important and widely used libraries, not available for free.
[/quote]
Now there is a surprise 
[quote]We’re working on moving to VC 2003 from vc6 for mustang. The ‘free toolkit’ from MS is not usable, as it’s missing some important and widely used libraries, not available for free.
[/quote]
I’m continually amazed how many people out there are still using VC++ 6.0. That compiler was initially released circa 10 years ago, and it hasn’t been patched in like 5. My guess is that the compiler allowed such incredibly broken behavior that the migration efforts to move up to a relatively conforming compiler are very significant.
Off the top of my head, I remember problems with template member functions, for loop conformance, auto_ptrs in containers (no warnings), multiple inheritance with virtual base classes, improperly namespaced classes/functions, non-inlined template definitions (ODR issues)…
It’s an example of how Microsoft has really hurt cross platform development. They focused so much on supporting their class libraries and proprietary funky compiler extensions, meanwhile putting no effort into fixing a horribly broken compiler.
I think that they should have been sued in countries like Germany which have very strict laws about advertising and standards conformance. Had they had to put a sticker on their box from the get go which said that their compiler had 152 known compliance issues, I think their market share wouldn’t have been so high.
God bless,
-Toby Reyelts
[quote]We’re working on moving to VC 2003 from vc6 for mustang. The ‘free toolkit’ from MS is not usable, as it’s missing some important and widely used libraries, not available for free.
[/quote]
What libraries?
Switching to a new compiler is not a simple task. Just consider the cost alone: we’d need to buy a license for everyone who compiles the code. That’s a lot of people in our case.
Another issue is that we already know the bugs in the old compiler, and switching to the new one is always risky since it’s very likely that we’ll run into new compiler bugs - and believe me, we run into them every time we try even a new compiler revision (ie there’s a reason the current jdk requires vc6 sp3, not 4), since jdk is such a huge codebase. So prior to the switch, lots of testing needs to be done - functional, performance, footprint.
And then there’s the problem that the new version of the compiler may not even be compatible - as it’s the case with vc7 (there’s a page from ms with the list of incompatibilities), so we actually have to port our code to the new compiler (which in some jdk areas is harder than in others).
But anyway, we’re making the switch this time (which I personally am very happy about, as I finally get to use the new tools instead of the 6 years old v.studio)…
Dmitri
[quote]Switching to a new compiler is not a simple task. Just consider the cost alone: we’d need to buy a license for everyone who compiles the code. That’s a lot of people in our case.
[/quote]
There’s always GCC + Eclipse ;D Works as well as VS in my opinion.
http://weblogs.asp.net/brianjo/archive/2004/04/17/115335.aspx
Scroll to the bottom and look at the last two entries. Evidently the omission of certain libraries is deliberate.
[quote]There’s always GCC + Eclipse ;D Works as well as VS in my opinion.
[/quote]
GCC produces extremely poor code for Intel. In fact last I heard Intel’s own compiler was significantly better than what MS was offering, but that was in the VC6 days.
I’m not sure how vc7 stacks up to the Intel compiler, but with vc6 I knew some guys that did very performance sensitive image processing applications and all of their release builds were done with the Intel compiler because they got a significant boost.
Please provide some links. GCC 3 optimizes much better than the old GCC.
From what I’ve read, Intel’s compiler is the best (which makes sense), followed by MS and then GCC 3. I think the difference between MS and GCC is small though.
[quote]From what I’ve read, Intel’s compiler is the best (which makes sense), followed by MS and then GCC 3. I think the difference between MS and GCC is small though.
[/quote]
In any case the performance of the C++ compiler used to compile a JVM is probably not as important as it is in other applications — hopefully most of the time will be spent in code generated by the JVM (which will be the same regardless of the C++ compiler used).
Hm, except that in the forthcoming hybrid VM it’d certainly be nice if the optimising JIT compiler part were a bit faster than it currently is.
Cas 
Shouldn’t the JIT be built in ASM?
Performance reasons?
Only nutters and Swedes try to write code in assembly language.
Cas
Or people trying to prove how great they are.
Kev
Isn’t that was princec said?
Sort of It helps to live in perpetual darkness hundreds of miles from any girls of course. The mind plays tricks.
Cas
Correct, the JVM spends most of its time in generated code. We’ve upgraded the Solaris C++ compilers several times over the past couple of years, and we’ve never seen any substantial improvements in performance for the VM. Oh and the new Sun C++ Compilers for Solaris (SS10) are better than the Intel C++ compilers for the X86
I’m not Swede, and I consider Macro Assembly as more simple and intuitive than C++. BTW they have women in Sweden, just they don’t care as much about them as women would like, or so they say.
While it wouldn’t be too much benefical to write JIT in assembly, possibly it could help by having cleaner code, and smaller executables. It would however help if JIT writers would have heavy experience with optimalizations in assembly. For example in holding critical parts of code in L1 cache, or estimation if SSE2 registers would be faster for one operation than 4 operations in general purpose registers.
It certainly wouldn’t hurt if someone would play with assembly for a week and create some GUI application, or JNI library in it. At least he wouldn’t talk nonsense like that above link “there is no lib.exe, so we can’t create DLLs” evrery respectable programmer is using link.exe with a nice library definition file. (It’s much cleaner that decorating method names with compiler hints.)
It reminds me… How would look compiled version of this code :
for(int c1 = 0; c1 < array.length; c1++){
something }
Difference between GCC and MSVC isn’t small, however. From a my half year old test GCC was close to JVM, rather down for my purpose (translated no easily optimisable code.), MSVC was by 1/5 faster.
[quote]Correct, the JVM spends most of its time in generated code. We’ve upgraded the Solaris C++ compilers several times over the past couple of years, and we’ve never seen any substantial improvements in performance for the VM. Oh and the new Sun C++ Compilers for Solaris (SS10) are better than the Intel C++ compilers for the X86
[/quote]
The important bits here would be in things like software blitting loops and that sort of thing, that is native anyway (I assume). But to be honest that is where going to assembler would make a lot of sense. Coding software blits, stretches etc. should be done in vectorized code… hand tuned SSE2 and the like. This is one of my ongoing rants that started when I realized how pathetically slow the JPEG loader is in the JRE. I bet going to a proper JPEG loader (e.g. Intel’s old jpeg library, or using their new DSP code that is optimized for the SSE2 instructions) would improve GUI startup time for an application that used JPEG images for button icons - just because the current loader is so extremely slow. (Can you tell I have a need to play motion JPEG in my Java UI ? And no, JMF is too broken to use for that sort of thing.)
I’m not sure how well assembler would help things like the ZIP deflating code, but something as fundamental as loading your resources from a compressed JAR should be optimized.
[quote]Please provide some links. GCC 3 optimizes much better than the old GCC.
[/quote]
I don’t have links, this was information from coworkers that had experience with MSVC, GCC, and Intel compilers. And as I said it is out of date, as they were comparing to VC6.
Of course I’ve also seen that Java 1.4.2 is faster than VC6 for some simple things - like basic conversion from YUV to RGB colors and printing the result. Microbenchmarks can be fun