 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic Page: 1 2 »» |
Last Thread Next Thread |
| Handling high perfomance 3d MATHS in the CLR |
|
 |
thona Banned Member since: 6/8/2002 From: Germany |
|||
 Posted - 12/31/2002 8:18:41 AM |
||||
| Hello, We are starting a research to work with 3d graphics from a C# level next year (with an intern supposed to hammer out the outline of a demo for a 3d engine). Well, in 3d you have to work a TON with floats, and we all know that this is NOT the best part of the CLR, performance wise - which is not really acceptable when doing work on the level we have to do. I thought of various ways to handle it, and the best thing I could come up with is this - which may have some pitfalls: (a) we use only float - which is supported by DirectX and good enough for our needs. (b) we throw out all the math stuff in the CLR, reimplementing even the functions in System.Math. Now, this is not as bad as it sounds - most are available in managed C++, and - contrary to System.Maths - are available as floats. I really dont like float math in the CLR, as System.Math is "too double" - a lot of important functions are not available with floats, and the constant doubles cause some not too good and efficient castings hundreds of thousand times a second. This would also give us a chance to "expose" some pretty nice stuff, like the assembly level "low resolution" sincos call, returning sinus and cosinos at the same time. Basiclaly this would mea nthat I would reimplement the functionality of the System.Math class (as needed) in a Managed C++ project. (c) in order to get better performance in the complex stuff, we thought of using native functions in the managed C++ classes and utilize SSE, 3dNow and other extensions (available as intrinsics in C## 7.0). This COULD in theory give us a huge performance boost. Please note that our "library" would go much further than the DirectX9 stuff - classes for box/box intersection atesting and collision detemrmination, for example - a lot of math running in the "native" part. Now, I have some areas I dont feel to comfortable with here. Basically - SOME of the functions we deal with are LOW LEVEL. My questions are basically: (a) is there a hidden performance overhead I do buy? I mean, does it make sense to handle stuff like matrix operations at this level, do I gain anything? Or would I loose all the advantage again because of a "managed/native" overheadI have not thought of? (b)can anyone advice on the "suitability" of using the SSE/SSE2 etc. Intrinsics compared to the regular C++ compiler? I mean, if I get the same performance anyways, I will not go THIS far. The goal, part of our research, is to have a high performance 3d optimised maths library usable from C# - something I dont see possible without this effort. At the same time I dont want to go into a dead end if oether people can give me some advice of their experience. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) |
||||
|
||||
|
Jerimiah Member since: 12/21/2002 |
|||
|
Posted - 12/31/2002 8:38:13 AM |
||||
| >>something I dont see possible without this effort. You are making a basic assumption here that is likely to be wrong. It is that you can program a better Math class than MS can, and that MS won't optimise the performance of FP operations in .NET. Assuming you are right, then you may or may not gain performance from your ideas, my instinct is you won't though. Managed C++ is only marginally faster than C#, and it primarily with operations where it can step outside the safe operations of .NET, C# can also benefit from these operations to a lesser degree, VB.NET cannot. However, to the best of my knowledge this won't help you with FP operations. You might gain some performance increase in FP operations if you implemented them in a COM object, but the COM Interop would kill that performance dead unless you could batch process them, and I don't see that as being a realistic option. If you are considering a Managed DX engine and are thinking of writing some parts in MC++ then you may as well write it all in MC++, there is no performance overhead for a C# assembly calling a MC++ assembly, so choice of language for the engine would seem to be an irrelevance here, the only issue should be that it is under Managed code. However, assuming you are wrong about the optimisations due to .NET....... Your C# engine will not be done for perhaps 6 months to a year I would guess. In that time I would expect some realistic enahncements to .NET - and MS have not exactly hidden what they know isn't optimised at the moment, notably featured are FP operations. It would be realistic to expect the performance of the internal Math class operations to far exceeed anything you could program when it has been properly optimised (your dislike for the bias towards doubles excepted). So the only issue here is a matter of timescales, and whether you work will be outdated before you complete it. My instinct is, run some basic tests to see if you can get the math performance you are looking for using the methods you have thought about. If you do then go ahead and develop the engine using the standard math functions now, and add your custom maths in later if .NET doesn't appear to be getting FP optimisations when you need them. That way you don't spend a lot of time trying to solve a problem that may not exist when you get to it. Whichever way you look at it, the engine does not appear to have any relation to the Math class. You can rewrite the Math class if you see some benefit to doing so completely independently of the actual engine, and with one simple change to a using statement every operation will use your new Math class. My instinct is also that MS will have optimised the DX9 Matrix object like crazy so I suspect you may not be able to improve matrix operations much (except where Matrix does not support your operations already). Hope that helps to clarify your thinking, there soesn't seem much point in discussing the deep down technical stuff as like everything, it is best tested  If you do get a nice shiny new Math class going I would certainly be one of the first to hand over shiny dollars (assuming MS haven't optimised .NET by then)... and possibly the same for a .NET/DX engine. Good luck |
||||
|
||||
|
thona Banned Member since: 6/8/2002 From: Germany |
|||
Posted - 12/31/2002 9:38:39 AM |
||||
quote: No, I am not. I am making an eduvcated quess based on the experience taken during the beta cycles or all relevant products (DirectX, .NET).. You have to understand the following: (a) The current CLR (including the upcoming 1.1) is very bad to take advantage of SSE, SSE2 etc. THis part is just not optimised. This results in - a performance problem. (b) The System.Math class does not expose trigonometric funtions for float data types, instead exposing doubles. THis causes - casts, which result in performance problems. BOTH parts are accepted shortcomings of the .NET framework and have been thoroughly discussed in the DirectX 9 beta cycle (which you would know would you have been part of the relevant beta teams). quote: There IS performance overhead for a C# assembly calling a native managed C++ function. Also, the math part is propably the best part which would even gain from being compiled "processor depending" in a SSE/3dNow/SSE2 fashion with machine code... quote: Thats a pretty stupid assumption to make, regarding me. Not that I dont make errors, but give n the fact that I am one of the vew people working with the CLR commercially for more than two years, having participated in app betas (starting befor even the public technical preview) and being one of the few people with a lot of COM interop work (Managed C++/Unmanaged C++ to C#) under my belly you can bet I know a hell of a lot more about the shortcomings and delicates of the CLR than you propably have even just forgotten :-) quote: It is not my dislike. Would it just be this, I would GLADLY make a very narrow wrapper, or efen use System.Math. The point is: (a) DirectX uses FLOAT. All data types are float. (b) System:Math exposes DOUBLE. All over the place. You might see that a and b make VERY inefficient algos. quote: Well, as you know the timeframe of .NET 2.0 (you do, dont you?) I can jsut say: thats a bet I am willing to take. quote: Thats the most ridiculous advice I have gotten so far. The reason I ask is BECAUSE I WANT TO KNOW WHETHER SOMEONE HAS AN EDUCATED IDEA BEFORE MAKING THESE TESTS. I would not have a problem with "trying it out", just it takes a month. I got some nice tips about a managed library for SSE2 available from intel, btw. - though on a location being more educated. quote: THIS is again porapbly not a bad advice based on YOUR knowledge of when .NET 2.0 and other stuff will be available. Given MY knowledge, I prefer to put someone on a math lib and THEN rip it out when MS fixes this part. quote: True. quote: Well, to MY knowledge they have not optimised it at all. They basically forward all requests to the native Dx9 functions :-) At least I remember someone mentioning this during the beta. quote: Well, we will proapbly put out a math namespace anyway - simply because the number of math functions is very high, and the stupid double problem DOES cost performance. Having Sin in xxx.Math.Trigonometry as a static function is propably not a bad idea - regardless how thin this actually turns. Our plans right now also call for a little different "matrix maths" than MS uses: Left hand coordinate system, but PROPER column/row coordinates, so that shaders dont need a transpose - and that you can use "normal math textbooks". Most of the Math namespace would though be used for "more intensve stuff" like intersection and collision testing - not the optimsied algos, but the core stuff (the formula parts). Here it looks like for SOME we could gainbig time :-) Lets see - oofficial procject start is end of january :-) Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) |
||||
|
||||
|
halfdan Member since: 12/11/2002 |
|||
|
Posted - 12/31/2002 11:59:58 AM |
||||
| Why not just use the Vector2,3,4, Matrix, Plan and Quaternion classes in DirectX9. There are native .net classes, and from my experience, are very fast, and layed out correctly. Their interface are very well designed, and provide just about any math function you can think of with these structs. The other nice thing about them is you can create a FVF using the Vector3 class for position and normal. BTW, I'm currently porting them to csgl so I can use them from a C# opengl application we are developing. This port will be open source if anyone is intersted. |
||||
|
||||
|
thona Banned Member since: 6/8/2002 From: Germany |
|||
Posted - 12/31/2002 12:36:52 PM |
||||
| Well, I have a couple of problems with the classes provided by DirectX. The main one being: THEY ARE NOT ENOUGH. Basically MS is just putting the most simple things there. Your math library might even decide to encapsule them :-) But basically it will also have functions for intersection tests, collision determination and all this complex stuff - things that MS has not included. This is basically where the point becomes much more critical. And as I am on this way, I will just rewrite all the Vector/Matrix stuff, too, to be consistent :-) The stuff is alraeady here in C++ form, so making it managed is not THE big deal :-) And I want to completly encapsulate DirectX away in the engine - we will use it internally, but there is no need for the engine user to have to include the Microsoft.DirectX namespace. Including JUST the WorldBuilder.Math and WorldBuilder.3dGraphics namespaces is just - cleaner from a hierarchy point of view. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) |
||||
|
||||
|
Jerimiah Member since: 12/21/2002 |
|||
|
Posted - 12/31/2002 1:25:16 PM |
||||
| >>I know a hell of a lot more about the shortcomings and delicates of the CLR than you propably have even just forgotten :-)<< Another wrong assumption by you - very sad really that you ask for advice, then proceed to tell people you know better.... You are still making assumptions - and as any good programmer knows, assmuption is the mother of all f**k ups. Good luck in your project. $50 says .NET v2.0 arrives before you complete your engine  [edited by - Jerimiah on December 31, 2002 1:25:53 PM] |
||||
|
||||
|
Wreakon Member since: 7/14/2001 From: Washington, USA |
|||
|
Posted - 12/31/2002 8:28:47 PM |
||||
quote: Those classes are meant for prototyping and are provided as help to implement much of the samples, Microsoft wouldn't have done it any other way. From my experience these are sometimes much slower than what can be done because they are intended for illustration and solid error handling. In the very least i would recommend encapsulating them. I know for a fact that I was able to optimize the Vec3 Normalization function using Assembler and got a significant performance boost (DX8 though). These math functions are a viable optimization since they will be used a lot, even though I understand that just optimizing the math functions alone will likely not yield better performance ( the weakest link rule ). ------- Homepage: http://students.washington.edu/andrey |
||||
|
||||
|
thona Banned Member since: 6/8/2002 From: Germany |
|||
Posted - 1/2/2003 4:29:18 AM |
||||
| Havee you guys looked into the implementation of these classes in ILDASM? What you will see is that basically all processing is forwarded to the DirectX Helper functions, which are external (i.e. in their own library). The CLR is not really able to optimise thiese calls out - after all, it is calling into an external Dll. This means loaind ghte cvalues onto the stack, calling, then unloading. For every single operation. I unified assembly using managed C++ could use native code (unmanaged classes wrapped by value classes) and the native code could have all the nice const definitions :-) BESIDES, if this library is then also implementing "higher up" mathematical problem solvers (like sphere/cone tests etc. - not scene graph management, but just the mathematical problem solvers), the C## compiler could make heavy use of inlining - in total the performance should be way higher. And I mean WAY higher. Even just throughz inlining and getting rid of the stack operations :-) Then, add to this that you could get rid of the ton of casts you have (a lot of functions only doubles), and - voila, here is your performance gain :-) quote: I have not asked for advice on the stuff which was commented wrongly. And your assumption is pretty wrong, you know. Not everyone here is a stupid student having no experience. IF you would have been in the DirectX beta groups you would have been able to participate in some discussions about the "tremendous" performance of the float maths in the CLR. And - are you arguing that calling an external dll for a simple vector/scalar multuiplication is faster than inlined code? Bosh, stop the stupidity here, please. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) |
||||
|
||||
|
Jerimiah Member since: 12/21/2002 |
|||
|
Posted - 1/2/2003 4:52:45 AM |
||||
| >>Havee you guys looked into the implementation of these classes in ILDASM? No - couldn't care less about the IL - you theorise by reading code, in real life cases you test. Creating a harness and program to test your theory should take less than 30 minutes - you have spent longer than that posting about it. >>and - voila, here is your performance gain :-) So do it then - stop talking and do it ... that's the difference betweeen a professional and an amateur... amateurs just talk and claim they know what they are talking about, professionals get on and do things. >>Not everyone here is a stupid student having no experience. And not everyone here with a string of MS qualifications lists them in their signature >>IF you would have been in the DirectX beta groups you would have been able to participate in some discussions about the "tremendous" performance of the float maths in the CLR. I was and I did (and on the .NET beta too)..... but I take it you assume you are the only person here with experience, another assumption. So back to the original point... if you are so good (as you clearly believe you are) then get on and do it, I'm sure MS would be very pleased that you can improve .NET so much beyond what their mediocre programmers managed. You may be right, you may be wrong - either way the more you talk and the less you test the longer it will be before you know. And as I said before - if you do come up with a high speed Math class then I would certainly buy it, so would many other people. Right - back to real work .... |
||||
|
||||
|
thona Banned Member since: 6/8/2002 From: Germany |
|||
Posted - 1/2/2003 7:44:44 AM |
||||
quote: The difference between an amateur and a pro is that the pro thinks first, while the amateur gets involved in various stupid "trying it out" projects. The timespan for a relevant (!) test is better considered to be in the one month area - not "30 minutes". And review with peer professionals (which takes out you, obviously) has already given me enough feedback to see it as very viable. Actually because other people HAVE ventured this way for other problems (image analysis, actually). And found tremendous performance gains. See - talk with pro's and you get advice. Stay here - and you end up disucssing with idiots like you. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) |
||||
|
||||
|
Jerimiah Member since: 12/21/2002 |
|||
|
Posted - 1/2/2003 8:21:59 AM |
||||
| >>Stay here - and you end up disucssing with idiots like you. Difference between amateur and professional - use of term 'idiot' when you know nothing about a person. Professionals act professionally, they don't boast about their qualifications in their signatures. [edited by - Jerimiah on January 2, 2003 8:22:41 AM] |
||||
|
||||
|
Jerimiah Member since: 12/21/2002 |
|||
|
Posted - 1/2/2003 8:22:17 AM |
||||
| Bah double posts Once again good luck Thomas. [edited by - Jerimiah on January 2, 2003 8:28:12 AM] |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 1/2/2003 9:25:18 AM |
||||
| i have seen nothing but antagonistic posts from thona. he has got to be the biggest prick MVP i've ever seen posting in an open forum. i feel sorry for MS that the likes of him represent what would otherwise be thought of as a fairly decent group of individuals. |
||||
|
||||
|
Darrell L Member since: 9/29/2002 |
|||
|
Posted - 1/2/2003 9:26:30 AM |
||||
| damn, meant to post that with my username. that last post was by me. |
||||
|
||||
|
kressilac Member since: 11/1/1999 From: Louisville, KY, USA |
|||
|
Posted - 1/2/2003 11:37:45 AM |
||||
| "...the C## compiler could make heavy use of inlining..." Obviously test any case where heavy use of inlining occurs. I've seen articles that purport inlining to be faster and then, in some cases slower. The reason lies in how the x86 architecture caches code segments to the CPU. Each instance of an inlined function is a UNIQUE code segment. Whereas a function could be loaded once into L1 or L2 cache and reused, an inline function stands a much greater chance of causing code segments to be erased from L1 and L2 cache, increasing cache thrashing. If your code uses lots of inlined functions in a series, there is a real good chance that the code will not be in the L1 or L2 cache when it is needed resulting in an order of magnitude slow down while the CPU waits for the code segment to be loaded. Many systems only have 512K or 256K L1 caches so it is easier than you think to thrash these caches and cause performance slowdowns. Your mileage may vary. Kressilac As with anything else, use of a technique in moderation is typically a good thing. Overuse will usually result in poorer performance. |
||||
|
||||
|
thona Banned Member since: 6/8/2002 From: Germany |
|||
Posted - 1/2/2003 12:00:01 PM |
||||
| This was a very good comment :-) You might note that I did not say "force" inlining. The basic idea I have is this: C++ compilers are still better at optimising code. WAY better than the CLR, and they have more info about it (like const functions etc.). Especially with complex 3d maths, the compiler may be able to inline (or optimise out) a lot more than the mixture of CLR code and an external C++ utility (which is what we get right now). A lot of this inlining is very simple, actually - a hand full of assembler calls, and the "push stuff on stack" overhead adds around 30%+ to the number of assembler calls. In this case the ability of the C++ compiler to optimize this out could be beneficial. I have decided, especially after discussions with Jan Griffiths, that the following approach is propably the optimal from a higher end: (a) the library will be written in Managed/Unmanaged C++. (b) primitives and algorythms will be unmananged C++ code, which gives a lot of optimisation leeway for the compiler. Native code will be enforced. (c) the primitives and algorythms will be wrapped up in managed C++ classes. This should result in the following behavior: (a) the slowest thing are "primitive operations in C#", like multiplying vector with a scalar. When chaining these, there is a managed/unmanaged change for every operation - which is a small overhead. (b) more complex operations are faster, as they basically have the overhead only once for the operation. The more complex the operation, the lower the overhead. The library will offer a replacement for the System.Math class that works with floats (like sin, cos etc.), which are sadly missing, and implement ,besides the primitives (like Vector, Matrix, Quaternion) also a number of more complex operations (OBB/OBB intersection tests etc.) - which the compiler can heavily optimise and which should probvide nice building blocks for higher up logic. I will have tests conducted on whether it is advisable to replace "simple C++ maths" with SSE instructions (like for a vector/scalar multiplication) - or whether the compiler is smart enough here. Anyhow, this should result in a much better performance than the DIrectX standard stuff - and will provide the "more advanced" tests and calculations that are terribly missing right now, but that everyone is duplicating anyway. Lets see - we start working against on the 6th, and we have a research project ok'ed for C# usage for 3d graphics, so I will put this lib into it. Results should appear by the end of january. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) |
||||
|
||||
|
Wikkyd Member since: 10/25/2002 From: 6667 feet below |
|||
|
Posted - 1/2/2003 12:58:54 PM |
||||
| Thona, Just a bit of advice here. You come here and ask for advice, and then when you get an opposing viewpoint, you resort to name calling. I dont know if you are correct in what you are saying or wrong, (I dont code .Net). But I will say this: Even IF what you are saying is correct, no amount of supposed credentials appended to your post will strengthen your position when you resort to juvenille name calling of people who were initially just trying to answer you question. A wise man once said, "you cant learn anything if you think you know everything......" |
||||
|
||||
|
thona Banned Member since: 6/8/2002 From: Germany |
|||
Posted - 1/2/2003 1:05:08 PM |
||||
| Wikkyd, I was not going to name calling because of an opposing viewpoint, but because of an opposing viewpoint that was SO bad in it's argumentation that it would make anyone working in my team to go a serious discussion about whether he should work professionally in the IT field. I keep my searches for knowledge on separate threads (especially in regards for gamedev.net), and if you want to read how things go on other places, have a look at the dotnet-clr thread regarding this topic (which is a mailing list). THIS there is how such things should proceed. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) |
||||
|
||||
|
Wikkyd Member since: 10/25/2002 From: 6667 feet below |
|||
|
Posted - 1/2/2003 1:14:26 PM |
||||
quote: So let me understand this correctly. You are saying you resorted to calling Jeremiah names not because he opposed your view, but because he did not oppose your view eloquently enough for your tastes? |
||||
|
||||
|
Darrell L Member since: 9/29/2002 |
|||
|
Posted - 1/2/2003 1:16:23 PM |
||||
| You'd be doing us all a favor, yourself included, if you just stayed out of these forums. I for one have seen enough of your posting history to know that you have added very little value to this site. The few times you offer anything other than your opinion have all bordered on insulting. Oh, and btw, MS has been contacted about the fact that you are mis-representing your MVP status. According to them you where given that honorary for the .NET IDE category, not C#, and not .NET. |
||||
|
||||
|
Darrell L Member since: 9/29/2002 |
|||
|
Posted - 1/2/2003 1:18:53 PM |
||||
| Sorry Wikkyd. My last post was meant for thona, not you. |
||||
|
||||
|
Wikkyd Member since: 10/25/2002 From: 6667 feet below |
|||
|
Posted - 1/2/2003 1:22:38 PM |
||||
| Oh I know Darell |
||||
|
||||
|
thona Banned Member since: 6/8/2002 From: Germany |
|||
Posted - 1/2/2003 1:29:53 PM |
||||
quote: You should learn reading. http://mvp.support.microsoft.com/default.aspx?scid=/default.aspx?scid=fh;en-us;mvpaward&nostyle=toc#faq1183 This points me out as a Visual C# MVP. Thats not IDE related - there are no "pure C#" MVP's, in terms of the categories MS has set up. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) |
||||
|
||||
|
Nypyren Member since: 8/20/2002 From: Eugene, OR, United States |
|||
|
Posted - 1/2/2003 1:44:58 PM |
||||
| Quick question: Are you calculating 3d matrices by HAND, or are you letting the D3D*X matrix functions calculate them? Because I don't see any reason to use Sin/Cos/Atan when I avoid angles like the plague. I just don't see any reason why you could use the slow double Math.* functions often enough to run into performance problems. |
||||
|
||||
|
thona Banned Member since: 6/8/2002 From: Germany |
|||
Posted - 1/2/2003 1:55:34 PM |
||||
| Well, I want to calcualte them by hand :-) And you dont only talk about matrix operations. I agree that as long as you stay that simple you dont need too much - but what about various "intersection tests"? You do get not too little stuff in there, regarding sin and cos functions and stuff like this. See, the problem I see with the D3D*X functions is that - they are external. There is no way that the compiler can inline or optimise some of their functionality - not even the CLR. They are external calls using standard call syntax, which means - that the parameters have to go onto the stack etc. No shortcuts, no parameters in registers and so forth. This is not TOO much an issue, though, as you pointed out - because you dont burn too much performance in matrix operations. But there are more complicated algorythms around. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) |
||||
|
||||
|
Page: 1 2 »» All times are ET (US) |
Last Thread Next Thread |
|
