Jump to content
The Dark Mod Forums

A chance to learn the innards of a compiler


revelator

Recommended Posts

Heh, we hit a huge snafu with the MSVC 2013 compiler and had to rollback to 2010 because of precision issues

(MSVC 2013 only does 32-bit intermediate precision unless you specify higher precision with flags and there is a "flag zoo"

with some producing better performance than others depending on the code... MSVC 2010 defaults to 80-bit intermediate precision

which matches the typical float units on CPU's from P3 era and up AFAIK).

 

Conspiracy theory:

 

AMD doesn't want developers doing floating point math on the CPU since the Bulldozer architecture gutted it in favor

of more simple integer cores with the idea that anything floating point related would be "offloaded to the GPU". Microsoft

has agreed to go along with this since their compiler competes against Intel's and they have a console partnership with

AMD. So Microsoft has made it difficult and byzantine to do high performance floating point math in their compiler.

In return, AMD gimps their OpenGL performance to coerce developers to DirectX or *Mantle (*which is really a platform

to train PC developers how to code low-level for consoles and ease PC to Console development).

 

Is that out-there enough? :laugh:

 

Interesting timing on this one Rev...

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Hehe i swear im not a microsoft conspirator :P but yeah that same snag was a real pain in my butt to.

Sadly theres one point that is in serious need of work on Open Watcom, the C++ compiler and its standard library are not done, so Doom3 with open watcom will most likely not work yet :(

The C compiler is complete though and works like a charm :) but we do need help on the C++ STL and compiler. P.Chapin is the lead dev (also the only dev) on the C++ compiler, but since hees alone

work has been rather slow. Unfortunatly my C++ fu is not strong enough to help building a standard library from schratch :S so if you know someone with a lot of C++ knowledge we could use his help :).

Link to comment
Share on other sites

Heh i had a hunch microsoft had some inner workings with AMD, must have started early back in the AMD K6-2 era where AMD started to gain serious momentum over intel.

For one i noticed that the most hated microsoft OS of all time ME ran like a charm on all boxes with AMD hardware (coincidence ???).

  • Like 1
Link to comment
Share on other sites

After reading about others ramming thee heads against the same pitfall im starting to wonder if it's really an AMD / Microsoft thing ?.

The problem as of now is that microsoft has changed the floating point precision in all there newest compilers to SSE math which would normally be a good thing or would it ?.

See the problem and also the reason why SSE and later are faster than FPU math is that SSE is actually less precise (less strict checking = more speed) in fact its off by exactly 4 bytes :)

yes someone actually tested it. Normally floating point math allows a certain skew which is normally quite ok but not if your application which was built with FPU math in mind suddenly finds that the values are off by the aforementioned 4 bytes. In case of the Doom3 engine we are so screwed its not even funny, you see idlib actually uses its own floating point library built on the FPU or x87 standard guess what happens when the microsoft compiler tries to optimize it with SSE math :) yup booom right in your face the values the engine expected are now far off = broken engine.

 

The reason i suspect more than foul play between AMD / microsoft is that the SSE instruction is actually intels, AMD had a similar optimization way way back in the K6 days called AMD-3DNOW which is now pretty much all but extinct, instead they use intels algorithms for SSE :) so does intel also want to chime in on the conspiracy ?. Sadly microsoft has pretty much stated that the x87 instruction will be dead from MSVC 2013 and onward newer to return :( despite that it actually is more precise. So as they said fix your code to work with SSE and dont call us back we will not call you.

Looks like someone will have to port idlib from rbdoom3 or rewrite the old one or port the one from rbdoom3. Well atleast the parts concerning floating point math :) unless microsoft left other surprises for us to find.

Link to comment
Share on other sites

See the problem and also the reason why SSE and later are faster than FPU math is that SSE is actually less precise (less strict checking = more speed) in fact its off by exactly 4 bytes :)

 

How come that 32 bit floats are the same speed as 64 bit double then? (EDIT: Although this is true, I didn't think it to the end)

I think the performance gain of SSE comes from vectorization/SIMD which is why e.g. an SSE sqrt on a single variable isn't much faster than sqrt().

Edited by Hiradur
Link to comment
Share on other sites

SIMD and vectorization are pretty much the same thing -> storing mutiple data in an array, theres some optimization going on behind the scene also ofc but the problem stands its off by 4 bytes ergo vanilla breaks, because its built with the x87 instruction in mind.

Now the funny thing when one thinks about it is that idlib actually does use SSE but it uses an inhouse assembler based version of it built against the x87 instructions.

Its also a fact that the x87 instructions have a higher internal precision than SSE but SSE has the advantage that it might offload that data on a GPU instead of solely on the CPU :)

somewhere i sense an upcomming directx12 as the reason why they want to force this, with AMD's mantle gaining improvements every day microsoft wants to make sure that directx stays ahead of OpenGL

even if they have to lobotomize there own compiler. Funny thing though i have not yet seen an OpenGL game make use of mantle but i guess better safe than sorry heh.

 

Some discussion elsewhere on the matter http://stackoverflow.com/questions/3206101/extended-80-bit-double-floating-point-in-x87-not-sse2-we-dont-miss-it

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Heh, we hit a huge snafu with the MSVC 2013 compiler and had to rollback to 2010 because of precision issues

(MSVC 2013 only does 32-bit intermediate precision unless you specify higher precision with flags and there is a "flag zoo"

with some producing better performance than others depending on the code... MSVC 2010 defaults to 80-bit intermediate precision

which matches the typical float units on CPU's from P3 era and up AFAIK).

 

Conspiracy theory:

 

AMD doesn't want developers doing floating point math on the CPU since the Bulldozer architecture gutted it in favor

of more simple integer cores with the idea that anything floating point related would be "offloaded to the GPU". Microsoft

has agreed to go along with this since their compiler competes against Intel's and they have a console partnership with

AMD. So Microsoft has made it difficult and byzantine to do high performance floating point math in their compiler.

In return, AMD gimps their OpenGL performance to coerce developers to DirectX or *Mantle (*which is really a platform

to train PC developers how to code low-level for consoles and ease PC to Console development).

 

Is that out-there enough? :laugh:

 

Interesting timing on this one Rev...

"not-so-conspiracy", man.

Edited by lowenz

Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...