C interface as core feature

[jacmoe]

I deactivated the Google.code repository - it will be deleted after .5 years - so now you've handling the official llcoi repository.

[galaktor]

Cool. Whoever wishes to get involved, ping me - obviously you can just fork and send a pull request on bitbucket.

I'll report any significant news here as well.

[bvanevery]

I just tried to pull from llcoi and it doesn't work. Server-side error.

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$ 

[jacmoe]

Try hg clone instead

It's mercurial, not git.

[bvanevery]

D'oh!

[tbz]

What I would really like is a C interface to Ogre, maintained as a core feature.

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.

[bstone]

What I would really like is a C interface to Ogre, maintained as a core feature.

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.

And "coded entirely in pure C" is why it won't ever happen

[tbz]

What I would really like is a C interface to Ogre, maintained as a core feature.

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.

And "coded entirely in pure C" is why it won't ever happen

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]

I hear ya but it's not because the original was in C and Ogre's terrain is in C++. And I don't have anything against C. It's just that sophisticated problems require sophisticated tools and a fully featured rendering engine is a sophisticated problem

[tbz]

It's just that sophisticated problems require sophisticated tools and a fully featured rendering engine is a sophisticated problem

Huh? What is that supposed to mean?

[bvanevery]

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.

What is the goal? It can't be performance, there is no advantage.

[tbz]

It can't be performance, there is no advantage.

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.

Now, I don't want you too take this the wrong way, because Ogre is a great engine and you guys have done a great job. Its just that, personally, I prefer trading the productivity of C++ for a more performance-oriented development style. It takes longer and is harder too use, but I find the benefits are worth it. That's my personal opinion, and I realize its not for everyone .

[bstone]

Sounds like you're talking about C# but calling it C++

Ogre has a number of performance related issues and they have very little to do with the fact that it's built with C++. 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

[tbz]

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

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.

In other words, it doesn't use the "one size fits all" (or "one class does everything") mindset. Instead it gets just the right shoe that fits the foot perfectly--It doesn't have shoelaces that are too long or too short, the shoe is just big enough but not too loose, etc--thus allowing for optimal walking free of tripping and blisters. That is, if you get the analogy .

[bstone]

First, you're comparing a general purpose built bus with a custom built sport car here. Second, believe me, you can have intrusive lists in C++ and they are looking much neater and are much easier to use.

[tbz]

First, you're comparing a general purpose built bus with a custom built sport car here

I figured you'd say that, but, again, you make an assumption.

Second, believe me, you can have intrusive lists in C++ and they are looking much neater and are much easier to use.

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.

[bvanevery]

I know this probably is going to ruffle some feathers, but the coding concepts introduced to C++ result in slower code, period.

So don't use "C++" concepts in performance critical areas of your code.

C++ trades performance for productivity and convenience.

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.

I have had this debate a hundred times with C++ lovers

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.

but I have (as of yet) to find a single C++ programmer who could best my C applications.

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.

[tbz]

You don't "best" people in applications land by winning a benchmark.

Nice straw man fallacy there. "Besting" was referring to the bench-marking, which is what we are talking about. Misrepresent, attack, profit.

I can think of a lot of reasons various people prefer C, but performance over C++ is not one of them.

Then you didn't think very hard. Either that or you are dogmatist, which wouldn't be a stretch either.

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.

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.

[bstone]

Instead of writing their own list, built just as they need it, they just instantiate a pre-existing, bloated solution (std::list).

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.

Have you ever thought why there aren't any Ogre-usk (and equally widely used) general purpose rendering engines developed in C? There's a reason for that. C is great, assembler is much better still, but you need sophisticated tools if you want to solve sophisticated problems efficiently.

[tbz]

That's a common misconception. If you look into the optimized compiler output for something that uses std::list you might be surprised.

No, I'm not surprised, because it is slower than mine, exactly as I expected it to be.

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.

The STL is the epitome of C++'s style of programming. Its the perfect example to show how C++ allows for bad code.

Have you ever thought why there aren't any Ogre-usk (and equally wide used) general purpose rendering engines developed in C?

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.

[bvanevery]

You don't "best" people in applications land by winning a benchmark.

Nice straw man fallacy there. "Besting" was referring to the bench-marking, which is what we are talking about. Misrepresent, attack, profit.

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.

[bvanevery]

The STL is the epitome of C++'s style of programming. Its the perfect example to show how C++ allows for bad code.

It is a common game industry practice to replace STL with an in-house implementation that is more performant for their specific circumstances.

[tbz]

It's not a strawman because you're focusing on performance to the exclusion of all other considerations.

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.

your mold wrote straight ASM code

Yes, I do. In fact, I love lisp and ASM, and I still use them to this day.

You're sounding like you think performance is the only thing anyone should worry about when developing an app

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#p488465

[bvanevery]

the coding concepts introduced to C++ result in slower code, period.

It's a hand wave if I ever heard one.

The rest of us know there are many cases where it's either not true, or irrelevant. When you make a comment like this, I don't see why you should be let off the hook regarding general application development considerations. The code isn't slower "period" if the end user cannot see any performance difference in how their app responds. Compiled ASM might take microseconds, interpreted PHP might take milliseconds, but if it's fast enough and nothing else is being impacted, who cares? The developer's time takes over, especially when that time is valued on the order of $100+/hr. Maintenance time is important too; it's often easier to correct a script. But since you're a Lisp fan you should know all of this. Most Lispers I've run into prefer C because it's easier to write Foreign Function Interfaces for C, and because C is more readily available on non-mainstream / embedded systems. C is also a simpler language to parse than C++, and that can be important for self-referential or bootstrapping systems (see Chicken Scheme-to-C compiler for instance). Has nothing to do with performance.

[tbz]

Compiled ASM might take microseconds, interpreted PHP might take milliseconds, but if it's fast enough and nothing else is being impacted, who cares?

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".