Re: C interface as core feature
Posted: Wed Oct 03, 2012 9:09 pm
I deactivated the Google.code repository - it will be deleted after .5 years - so now you've handling the official llcoi repository.
Support and community hang-out spot for Ogre3D
https://forums.ogre3d.org/
Code: Select all
bvanevery@nomad:~/devel$ git clone https://bitbucket.org/galaktor/llcoi
Cloning into 'llcoi'...
WARNING: gnome-keyring:: couldn't connect to: /run/user/bvanevery/keyring-2IU3g3/pkcs11: No such file or directory
fatal: https://bitbucket.org/galaktor/llcoi/info/refs not found: did you run git update-server-info on the server?
bvanevery@nomad:~/devel$
Yes, please! Its a step in the right direction IMO, what I would really like to see an Ogre-usk engine coded entirely in pure C.jacmoe wrote:What I would really like is a C interface to Ogre, maintained as a core feature.
And "coded entirely in pure C" is why it won't ever happentbz wrote:Yes, please! Its a step in the right direction IMO, what I would really like to see an Ogre-usk engine coded entirely in pure C.jacmoe wrote:What I would really like is a C interface to Ogre, maintained as a core feature.
I am caught up in two big projects right now, but once I have some free time I plan to do just that . I was developing one about a year ago that showed some promise. I did Ogre port of a terrain module in the said engine. Porting it to Ogre it gets about 1/4 of the framerate .bstone wrote:And "coded entirely in pure C" is why it won't ever happentbz wrote:Yes, please! Its a step in the right direction IMO, what I would really like to see an Ogre-usk engine coded entirely in pure C.jacmoe wrote:What I would really like is a C interface to Ogre, maintained as a core feature.
Huh? What is that supposed to mean?bstone wrote:It's just that sophisticated problems require sophisticated tools and a fully featured rendering engine is a sophisticated problem
What is the goal? It can't be performance, there is no advantage.tbz wrote: Yes, please! Its a step in the right direction IMO, what I would really like to see an Ogre-usk engine coded entirely in pure C.
I know this probably is going to ruffle some feathers, but the coding concepts introduced to C++ result in slower code, period. C++ trades performance for productivity and convenience. Its a trade-off. I have had this debate a hundred times with C++ lovers (and I don't think I've ever convinced one of them, lol), but I have (as of yet) to find a single C++ programmer who could best my C applications. Its like the engine I was referring too. In my engine that terrain renders at around 200 FPS. On the same PC being ported to Ogre it gets around 50 FPS . My previous engine was doing bloom/hdr passes and shadow mapping, too! I have those disabled in my Ogre version right now.bvanevery wrote:It can't be performance, there is no advantage.
So you assume. In all actuality the performance my engine has over Ogre is thanks to how it handles threads, rendering tasks, input and the minimalistic design. Instead of instantiating a monstrous class that includes a bunch of unneeded overhead (std::list<MyObject>), I simply implement my own list built right into the data structure, optimized specifically for that specific data structure and its uses.bstone wrote:Saying that C code gives 4x more FPS than equivalent C++ code is not a clever idea especially when 95% of the processing is done on the GPU
I figured you'd say that, but, again, you make an assumption.bstone wrote:First, you're comparing a general purpose built bus with a custom built sport car here
Exactly my point! You are trading performance for the convenience of productivity. Its a mindset that plagues C++ devs. Instead of writing their own list, built just as they need it, they just instantiate a pre-existing, bloated solution (std::list). In C, there is no STL that implements lists (there are some, but their licensing are not favorable to commercial applications). Between that and the coding style that C forces it makes the programmer more aware of the code they are writing which leads to better, more efficient code. Most people can't stand writing/debuging/profiling their own list class, they just like it to be done with it. That's what C++ is for: Just to code it and be done with it ASAP.bstone wrote:Second, believe me, you can have intrusive lists in C++ and they are looking much neater and are much easier to use.
So don't use "C++" concepts in performance critical areas of your code.tbz wrote: I know this probably is going to ruffle some feathers, but the coding concepts introduced to C++ result in slower code, period.
Productivity and convenience? Surely you jest. Well maybe not if your world view is "compared to C," but there are a bazillion higher productivity languages out there. Assuming those languages fit one's problem domain and the performance hit is acceptable.C++ trades performance for productivity and convenience.
I almost hate C++. I helped found the Seattle Functional Programmers. I can think of a lot of reasons various people prefer C, but performance over C++ is not one of them.I have had this debate a hundred times with C++ lovers
If you point me at your game, or some other kind of complete and shipped 3d app, that does something remarkable, I'll look at it and then we'll see if I'm impressed. You don't "best" people in applications land by winning a benchmark.but I have (as of yet) to find a single C++ programmer who could best my C applications.
Nice straw man fallacy there. "Besting" was referring to the bench-marking, which is what we are talking about. Misrepresent, attack, profit.bvanevery wrote:You don't "best" people in applications land by winning a benchmark.
Then you didn't think very hard. Either that or you are dogmatist, which wouldn't be a stretch either.bvanevery wrote:I can think of a lot of reasons various people prefer C, but performance over C++ is not one of them.
By the same logic, provide me with a C++ app that does something remarkable and I will be impressed. Furthermore, prove that it couldn't be implemented more effectively as a C program. Do you notice how worthless arguments points like this are? Lets avoid them for more productive methods, please.bvanevery wrote:If you point me at your game, or some other kind of complete and shipped 3d app, that does something remarkable, I'll look at it and then we'll see if I'm impressed. You don't "best" people in applications land by winning a benchmark.
That's a common misconception. If you look into the optimized compiler output for something that uses std::list you might be surprised. Also, STL is not C++. It's a library, a very good one indeed, but a library after all. You don't like it - you don't use it.tbz wrote:Instead of writing their own list, built just as they need it, they just instantiate a pre-existing, bloated solution (std::list).
No, I'm not surprised, because it is slower than mine, exactly as I expected it to be.bstone wrote:That's a common misconception. If you look into the optimized compiler output for something that uses std::list you might be surprised.
The STL is the epitome of C++'s style of programming. Its the perfect example to show how C++ allows for bad code.bstone wrote:Also, STL is not C++. It's a library, a very good one indeed, but a library after all. You don't like it - you don't use it.
I know why. I even mentioned it last post. Convenience. Who wants to write their own list class when they can just use std::list? C++ makes trades-offs for productivity.bstone wrote:Have you ever thought why there aren't any Ogre-usk (and equally wide used) general purpose rendering engines developed in C?
It's not a strawman because you're focusing on performance to the exclusion of all other considerations. Let me be blunt: if the only thing you are doing by using C all the time instead of C++ is winning benchmarks, I'm not impressed. It's a narrow career skill, a specialized activity, and it doesn't make it easy or likely to ship completed games (or other apps if you prefer). I used to be one of those, a 3d assembly code optimization jock back in the day. Claiming C is so great makes me laugh, because back in the day "real" developers in your mold wrote straight ASM code. Nowadays one still could, seeing as how x86 has taken over the desktop space, where the best performing 3D HW is available. When I quit my job many years ago and struck out on my own, I had way too much of this optimization jock mentality and I was not well rounded as to what I could produce. I went bankrupt pursuing premature optimizations, to "win benchmarks." If you haven't fallen off that cliff for some reason, either because you're wiser or more experienced than you're letting on, or just lucky, well power to you. You're sounding like you think performance is the only thing anyone should worry about when developing an app, and that's a disservice to newbie developers.tbz wrote:Nice straw man fallacy there. "Besting" was referring to the bench-marking, which is what we are talking about. Misrepresent, attack, profit.bvanevery wrote:You don't "best" people in applications land by winning a benchmark.
It is a common game industry practice to replace STL with an in-house implementation that is more performant for their specific circumstances.tbz wrote: The STL is the epitome of C++'s style of programming. Its the perfect example to show how C++ allows for bad code.
We where talking about performance. Expanding the context to include other aspects is a straw man fallacy. The argument is whether C coding produces better, more efficient code, not whether or not C is practical because of its productivity. By expanding the context you make it more attackable. What you fail to understand is that by proving the misrepresented argument wrong you do not prove the actual argument wrong. Its a straw man, a logical error. I can spoon feed you some more and go over the logic step-by-step if you would like.bvanevery wrote:It's not a strawman because you're focusing on performance to the exclusion of all other considerations.
Yes, I do. In fact, I love lisp and ASM, and I still use them to this day.your mold wrote straight ASM code
Never once did I say that. In fact, I said the exact opposite. Please re-read my posts, in particular the second paragraph of this one: http://www.ogre3d.org/forums/viewtopic. ... 87#p488465You're sounding like you think performance is the only thing anyone should worry about when developing an app
It's a hand wave if I ever heard one.tbz wrote: the coding concepts introduced to C++ result in slower code, period.
Yet another straw man fallacy. Can you not provide a legitimate argument? You take Ogre and 3D applications (where performance is a huge issue) and you apply it to PHP (where performance isn't as big of an issue). Let me emphasize this again: You cannot prove an argument wrong after deliberately misrepresenting it. Prove to me that Ogre couldn't benefit from a leaner coding style. Don't prove to me that in PHP its ok to have slow code. "Its Ok to have slow PHP code" != "its Ok to have slow code in real-time, performance heavy applications".bvanevery wrote:Compiled ASM might take microseconds, interpreted PHP might take milliseconds, but if it's fast enough and nothing else is being impacted, who cares?