Random Visual Glitch? in PrBoom+

entryway said:

Is fast math is enabled?

If you mean the VC9 floating point fast options /fp:fast? Yes.

entryway said:

Btw, at same position I have ~80 fps with prboom-plus. OpenGL is about 1.5-2x slower there, heh

Maybe you should enlighten us how you manage such high FPS and what exactly you think it is that makes EE slow. Especially since you're always on about it so much. Don't take it the wrong way, I'm not pissed off, but you do have a habit of popping up all the time to make this point or hint around about it like you find it somehow amusing.

There has never been any reason for EE and PrBoom-Plus to be rivals or compete to see who can get the most FPS. Sharing advancements would be a much more productive mode of operation for both ports.

You 'answered' my small 'btw' remark instead of question.

Quasar said:

there was an average gain of 12 FPS in the final room of Sunder MAP14 after enabling SSE2

entryway said:

what is "gain of 12 FPS"? 4000+12 or 3+12?

Quasar said:

In this case the gain of 12 was the difference between irritating lag and playability.

entryway said:

http://prboom-plus.sf.net/ee_sunder_test.zip
eternity -file Sunder.wad -loadgame 0 -timedemo sunder

The latest release of EE, Core2Duo, default cfg, 1024x768f, no wipe

"Win32 Binaries" - 28.3 fps
"Win32 "Plus" Binaries" - 31.8 fps

I think this is just a difference between VC6 and VC2008 compilers.

What difference do you have? What kind of processor? Can you compile two versions (with and without SSE) with VC2008? I ask, because I think I will not have any difference between SSE and non SSE versions on my Intel Processor.

I still do not believe in sse magic for doom ports.

From your post it is something like:
~20 (irritating lag) + 12 (from sse) = 32 fps (playability, almost 35 Hz cap)

Just can't believe that. 1% - ok, 5% - probably, but not 50-60%

Probably sse makes sense for vc2008 just because it uses sse for memcpy / memset stuff after enabling. Not because sse math and not +60%! in speed. Intel Compiler uses sse for such functions _always_ when it is possible. Resulting exe has several implemetation, with and without sse, it is dynamic.

Btw, IIRC Intel Compiler always forces slowest x86 implementations for _any_ AMD processors.

entryway said:

Btw, IIRC Intel Compiler always forces slowest x86 implementations for _any_ AMD processors.

That's just petty. I'm amused.

Gez said:

That's just petty. I'm amused.

I read it somewhere here I think:
http://www.agner.org/

Got it:
http://www.agner.org/optimize/blog/read.php?i=49#49

Sounds nice, but the truth is that the CPU dispatcher didn't support SSE or SSE2 or any higher SSE in AMD processors and still doesn't today (Intel compiler version 11.1.054)

SSEx & AMD - well that's what you get for being a traitor.

If you want to be sure that an advanced instr.set is used, even on an AMD, just use the http://blog.kaetemi.be/post/2009/10/25/SSE2-memcpy.
Of course the hassle of cpuid'ing and function pointing is to be managed by you.
Agner Fog is also pissed by the dubious dispatching politics.
I guess Intel will NEVER change that.

_bruce_ said:

If you want to be sure that an advanced instr.set is used, even on an AMD, just use the http://blog.kaetemi.be/post/2009/10/25/SSE2-memcpy.
Of course the hassle of cpuid'ing and function pointing is to be managed by you.
Agner Fog is also pissed by the dubious dispatching politics.

Agner Fog also wrote own asmlib (memcpy, strlen, etc)

His comparison:


Asmlib is very easy to use. Easiest method is about 8-10 key presses in MSVS :)

entryway said:

Just can't believe that. 1% - ok, 5% - probably, but not 50-60%

Probably sse makes sense for vc2008 just because it uses sse for memcpy / memset stuff after enabling. Not because sse math and not +60%! in speed. Intel Compiler uses sse for such functions _always_ when it is possible. Resulting exe has several implemetation, with and without sse, it is dynamic.

Btw, IIRC Intel Compiler always forces slowest x86 implementations for _any_ AMD processors.

I didn't attribute the *entire* gain to SSE2 - I did note that several other optimizations were enabled at the same time. I am not sure of the amount each individual one contributed to the increase but the overall increase was pretty dramatic, I felt.

I have a Core 2 Quad so I'm not subject to AMD oddities. My older XP box is an AMD64 but it's of a completely different, much older class, and so performance comparisons between it and the C2Q are pretty meaningless.

I guess FPU is still on the whole slower than fixed point; some testing I have done since the start of this thread has convinced me of that. However, it is still the cleanest solution to the precision problems that you're going to find.

Quasar said:

I didn't attribute the *entire* gain to SSE2 - I did note that several other optimizations were enabled at the same time. I am not sure of the amount each individual one contributed to the increase but the overall increase was pretty dramatic, I felt.

Did you try to disable sse2? I think it could be even faster. For example, x64 makes prboom-plus slower (especially with Intel compiler) at least on my Core2Duo, SSE also does not give any improvements (IIRC it also makes executable slower a little).

Quasar said:

I have a Core 2 Quad so I'm not subject to AMD oddities.

Or goodies :) I suppose x64 prboom+ should not be slower than x86 on AMD

entryway said:

Agner Fog also wrote own asmlib (memcpy, strlen, etc)

His comparison:
...
Asmlib is very easy to use. Easiest method is about 8-10 key presses in MSVS :)

People like Agner keep the ball rolling. A bona fide scientist and engineer.

_bruce_ said:

People like Agner keep the ball rolling. A bona fide scientist and engineer.

... and releases something fundamental as this under the GPL so nobody working on anything even semi-commercial can use it. How stupid is that? :(

Note to all open source fetishists: This is precisely the kind of code where you use a liberal license unless you want to be accused of pushing an agenda.

Graf Zahl said:

... and releases something fundamental as this under the GPL so nobody working on anything even semi-commercial can use it. How stupid is that? :(

Note to all open source fetishists: This is precisely the kind of code where you use a liberal license unless you want to be accused of pushing an agenda.

Heh. Says guy that put "disclosure of project's entire source code is mandatory" in his license.

tempun said:

Heh. Says guy that put "disclosure of project's entire source code is mandatory" in his license.

It is a major difference to force open source on a large project as opposed to a library that's supposed to be used by said larger projects. Totally different scope.

The thing with this asmlib is that it can only be used in projects that fully comply with the GPL, making it essentially useless.

Graf Zahl said:

The thing with this asmlib is that it can only be used in projects that fully comply with the GPL, making it essentially useless.

Not to projects that actually maintain licensing validity by avoiding proprietary libraries and game engine code that's under non-libre licenses.

And I am aware of some of the disadvantages it has, such as there being no half-decent sound library that is under BSD or GPL. However, we and many other projects do manage.

It is pretty much a problem unique to the ZDoom codebase. And I hate to say it but it almost feels a bit hypocritical to have complaints about it coming out of the ZDoom camp, seeing how the situation with voxels was handled and how that has affected Eternity adversely.

r_voxels.cpp will remain forever in the repository as a testament to Randy Heit's Build-fueled feature sniping. I hope that it is a monument that he can feel proud of inspiring.

Quasar said:

It is pretty much a problem unique to the ZDoom codebase. And I hate to say it but it almost feels a bit hypocritical to have complaints about it coming out of the ZDoom camp, seeing how the situation with voxels was handled and how that has affected Eternity adversely.

While I understand the bitterness over the theft of thunder, I don't see how that has affected Eternity adversely directly. Randy isn't responsible for Stroggos not following on his promise, as far as I know. (Unless I missed some IRC drama? I never go on IRC.)

Quasar said:

Not to projects that actually maintain licensing validity by avoiding proprietary libraries and game engine code that's under non-libre licenses.

Ugh...

I'm not concerned about ZDoom here but a general attitude. ZDoom wouldn't profit much from this kind of optimization anyway (it just doesn't make sense to optimize code that takes less of 1% of execution time) so it'd be more of a hassle than an asset.

This would have been something I could have used in some stuff I do for my job but since it's all closed source proprietary software by theory I'd not even be allowed to look at this stuff to optimize performance. That's just plain idiotic for something that's supposed to demonstrate how to make these functions faster.

When it comes to libraries, I think most people make them so that the general public can profit from them in one way or another.

However, if you release a library under the GPL you are limiting its potential users to the relatively small group of Open Source software that's released under the GPL. I just can't consider that a smart move. There's good reasons why the LGPL exists and even that's grossly unsuitable for any kind of code that would require static linking.

So, who will end up using this? I guess nobody. Those who would like to can't use it due to the license and most of those who could use it most likely won't because it'd complicate their project's setup in an undesirable way.

End result: big fail.

Quasar said:

Don't take it the wrong way, I'm not pissed off, but you do have a habit of popping up all the time to make this point or hint around about it like you find it somehow amusing.

[CaptainObvious]
His source port achieves higher FPS than yours, therefore his genitals are proportionately larger?
[/CaptainObvious]

Jokes apart, I too agree that this (and some other similar/related) attitudes of casting FUD or childish penis envy insinuations on each other's source port don't help Doom as a whole, in particular for what regards technical innovations. Source ports are out there to be played and studied by fellow source port authors or merely curious programmers, and are actually a very rewarding hobby. There's no need to shit all over it, no matter how wittily or subtly one thinks he can pull it out.

That was my mistake, I was not careful during reading. I read after enabling SSE2 and "forgot" about , link-time code generation w/full program optimizations, favoring fast floating point ops over accuracy, and setting inlining to compiler initiative. SSE2 itself does nothing I think.

I do not understand why Quasar uses VC2008 for "pro" binary and slow vc6 for compatible binary. VC2005 merges both

Graf Zahl said:

(it just doesn't make sense to optimize code that takes less of 1% of execution time) so it'd be more of a hassle than an asset.

Right. If we had problems with memcmp or memset being our big time eaters, we'd be in trouble for sure. Last time I profiled Eternity, memset was somewhere in the bottom of the chart despite having a very large number of calls to it (EE memsets almost all memory allocated for security reasons).

Graf Zahl said:

That's just plain idiotic for something that's supposed to demonstrate how to make these functions faster.

When it comes to libraries, I think most people make them so that the general public can profit from them in one way or another.

It's here that my issues kick in. You're making an assumption or two there that A. the author created it for demonstration purposes and B. that he wants/cares that everyone can use it. It might seem childish or vindictive at some level, but if the author actually ideologically believes in free software then he has the right to restrict his property in this way. I don't agree that it's a good thing myself, though, despite how much I do support free software. Libraries are inherently more useful under a more liberal license.

Graf Zahl said:

So, who will end up using this? I guess nobody. Those who would like to can't use it due to the license and most of those who could use it most likely won't because it'd complicate their project's setup in an undesirable way.

Any compatibly-licensed open-source multimedia app with high memory bandwidth would benefit, and I imagine it could also be useful to some scientific distributed computing apps to make sure they are maximizing use of their borrowed CPU cycles (wherever they're not running on the GPU now). I'm sure it has found use somewhere, just not in nearly as many places as it theoretically could.

entryway said:

That was my mistake, I was not careful during reading. I read after enabling SSE2 and "forgot" about , link-time code generation w/full program optimizations, favoring fast floating point ops over accuracy, and setting inlining to compiler initiative. SSE2 itself does nothing I think.

I do not understand why Quasar uses VC2008 for "pro" binary and slow vc6 for compatible binary. VC2005 merges both

Eternity no longer compiles in Visual C++ 6.0 and has not done so since porting to C++. It has some kind of strange compiler bug that makes it think all our static arrays of structures are a single structure and there is no known workaround that I can find for that problem. It also has incompatible/non-standard function overload resolution semantics that cause it to not be able to deal with the operator << functions declared by the SaveArchive class.

Visual C++ 2005 *is* used for the Win98/NT4-compatible build. I do not use it for the "pro" build, if that's what you want to call it, because I just happen to have Visual C++ 2008 Professional. Why would I drop back to an earlier version when there's no advantage and many possible disadvantages?

Just to satisfy you though, I'll do some profiles with SSE2 codegen and without. If SSE2 is actually making Eternity slower, I'll happily disable it.

Quasar said:

but if the author actually ideologically believes in free software then he has the right to restrict his property in this way.

... but then I have the same right to question his motivations. I believe in free software, too, but since I work in programming I also know that pushing it to the limits is much more destructive than some people want to believe. If everything was free I'd be out of a job.

Quasar said:

just not in nearly as many places as it theoretically could.

Which is precisely the issue I have with it. He goes all the length to profile the compiler-provoided implementations, then shows his own but if you check it out it's 'Eek, screwed you! It's for free open source software only!'

The funny thing about the whole GPL deal is that it's to address a problem with the Intel compiler, which isn't GPL. If he has strong ideological reasons to push the GPL agenda, then he should be consistent and restrict himself to GCC...

Graf Zahl said:

... but then I have the same right to question his motivations. I believe in free software, too, but since I work in programming I also know that pushing it to the limits is much more destructive than some people want to believe. If everything was free I'd be out of a job.

Does the author not offer any commercial licenses to businesses and individuals? Dual-licensing GPL/Commercial gives a library actual value, because if the software or library is so damn good that you need it in a proprietary codebase it's worth paying for, right?