Quasar
Moderator
Posts: 4615
Registered: 08-00 |
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.
Last edited by Quasar on 11-16-11 at 13:27
|
11-11-11 12:20 
