(L) [2007/11/22] [tbp] [msvc2k8] Wayback!As usual it's pretty impossible to find a proper changelog, we're all supposed to drink the proverbial "New & Improved" Kool-Aid.
Fear not! Here comes [LINK http://blogs.msdn.com/vcblog/archive/2007/10/18/new-intrinsic-support-in-visual-studio-2008.aspx "New Intrinsic Support in Visual Studio 2008"].
Two things stand out
_InterlockedCompareExchange128 { 64bit CAS2 anyone? }
_mm_cast*
Better late than never.
edit: there's also some TR1 support of some sort; if anyone has a reference...
_________________
May you live in interesting times.
[LINK https://gna.org/projects/radius/ radius] | [LINK http://ompf.org/ ompf] | [LINK http://ompf.org/wiki/ WompfKi]
(L) [2007/11/23] [greenhybrid] [msvc2k8] Wayback!uh oh:
(L) [2007/11/23] [lycium] [msvc2k8] Wayback!no inline asm on x86-64 is already the case with 2005 :|
(L) [2007/11/23] [lycium] [msvc2k8] Wayback!tbh i hate at&t syntax, and am done with asm... intrinsics all the way :)
(L) [2007/11/23] [tbp] [msvc2k8] Wayback!Between one implementation that asks the compiler to parse and completly model a stream of instructions and another that relies only on the programmer to precisely describe the interface to such stream in terms of input/output/side-effect constraints, guess which one is harder to get right.
"the optimizer does not work well with inline asm code" is the consequence of a bad design, not AT&T syntax. A very poor argument in any case.
(L) [2007/11/23] [lycium] [msvc2k8] Wayback!needless to say, i don't use msvc for its awesome codegen :/
(L) [2007/11/23] [tbp] [msvc2k8] Wayback!As far as i know, msvc doesn't try to optimize in any way whatsoever around inline asm; it merely takes notice of clobbering, so if you taint a register it gets reloaded (and you get the same kind of trouble on prologue and so on). It's really dumb and really fragile. Yet it avoids function calls - a no-no without inline asm - so it's better than nothing when kludging.
But please stop referring to inline asm constraints as AT&T, it's completely orthogonal (yay! i said orthogonal!).
_________________
May you live in interesting times.
[LINK https://gna.org/projects/radius/ radius] | [LINK http://ompf.org/ ompf] | [LINK http://ompf.org/wiki/ WompfKi]
(L) [2007/11/27] [Michael77] [msvc2k8] Wayback!Just did an initial test with the 2008 Compiler and the source code from the Vertex Culling paper on a Xeon P4:
msvc8 (visual studio 2005) compiler needs about 7.7 cycles per triangle.
msvc9 (visual studio 2008) compiler needs about 5.1 cycles per triangle.
Seems like they actually did some work on the compiler, can´t wait to test it on a more advanced example.
(L) [2007/11/27] [lycium] [msvc2k8] Wayback!1. wow, that's quite an improvement!
2. wow, people still use p4s?! ;)
(L) [2007/12/12] [cignox1] [msvc2k8] Wayback!Hi all, pehaps I'm off topic, but are you saing that gcc produces faster code than vc? I was able to get a (20%? I think something like that) gain just switching from code::blocks with gcc to Visual Studio 2005. Unless the gcc has to be hand tuned (in terms of compiling options) to get the max optimization settings, I experimented a big improvement using msvc.
If you say that it is the way around, I should really give it a second chance [SMILEY Smile]
(L) [2007/12/12] [lycium] [msvc2k8] Wayback!apparently the newer gcc versions (3.3 and 3.4) are better than msvc. however, i only tried recompiling a single application of mine to use gcc 3.4 with tbp's help, and found it to be significantly slower :/
(L) [2007/12/12] [Ho Ho] [msvc2k8] Wayback!I think you mean GCC 4.1/2/3?
_________________
In theory, there is no difference between theory and practice. But, in practice, there is.
Jan L.A. van de Snepscheut
(L) [2007/12/12] [lycium] [msvc2k8] Wayback!ah yes, sorry
(L) [2007/12/12] [Michael77] [msvc2k8] Wayback!Apparently it depends a lot on how you write your code. The intel compiler is supposed to compile the fastest code (at least as good as gcc) but for me it was about 10% slower than msvc8 code on a Core2Duo (with all possible optimizations turned on). For each compiler you will need to know its problems (operator overloading for example is very, very slow with msvc8 but seems to work ok with msvc9) and other issues (safe-stl for msvc can prevent many functions from getting inlined for example).
So in my opinion there are other things that are more important than getting 5% more speed. I wouldn´t ever want to use gcc on windows for example since I am lazy and most libraries come in msvc format.
(L) [2007/12/12] [lycium] [msvc2k8] Wayback!quiet, you! just recently you got a 3x speed increase because you didn't know gcc has optimisation flags [SMILEY stick out tongue]
(L) [2007/12/12] [lycium] [msvc2k8] Wayback![SMILEY Boo hoo!]
back