pouët.net

doom: hey, just wanted to point some facts, that's all. :)

I agree with your entire post above. I'm not fond of having a compiler running in my back, trashing my caches. Even if it was faster than anything, I wouldn't use Java which don't deliver the same amount of control as compared to C++.

It's also true that JIT optimizers need soundness in static analysis (ie, computing the set of possible values), which I think can be defeated easily in a real situation.

And don't start me on JNI...

doom bro, you coming sundown this year?

I wouldn't know about Java, since I've only used Java while doing some school tasks, however, I've written plenty of realtime c# (which also has most of the Java problems you write above), and with a good understanding of the resource allocator and the garbage collector, you could get some very nice performance with it without even using any unmanaged code.

Plus, you have unmanaged code at your disposal in case you need a very tight loop, or pointer accessing... it all comes with an overhead, yes, but it works, and it's decently performant for anything i've tried (not C++ performant, but close).

Also, the JIT is amazingly well done, and at some points and in some (rare, yes) events, it might even lead to being better than native code, since it gets compiled on the fly to processor-optimized code, without needing any assembler or optimized code-path in C++.

Just my two cents :-)

Having said that... libcinder looks pretty decent too... i might get the dust off the C++ compiler and kick my arse to do "something" again... or maybe not :-)

LIES. At most it's equal, not better. Or your compiler / language sucks.

did anyone try to recompile it in other than VS ?

xernobyl > get a clue...

there are optimizations a JIT compiler can do that can't be done at compile time

anyways; the topic is libcinder; not how little hardcore coders know about programming languages...

however, a JIT doesn't have the liberty to do certain optimization a plain old compiler can do either.

well i don't see many good demos on java *period*.

Er, I'm with xernobyl here... "better than native code" is gibberish. What's the processor executing, then, Chuck Norris brainwaves?

Unless you mean "better than non-optimally-written native code", in which case... duh.

shut up and go make a demo about it, using libcinder.

using libcinder and JNI so it can be in java !

xernobyl, what i mean is, the JIT compiler can do different optimizations for different processors at runtime... using a C++ compiler, unless you do all those code-paths yourself, it can only optimize for some architecture at compile-time, thus, upon normal usage (where the programmer doesn't write every single possible code-path for different processors optimization), in some occasions, the JIT can make better code for the platform it's running on.

Plus, if some other instruction set may appear in the future, in case the JIT gets updated for it, your application would already be optimized, vs. having to write the new codepath and compile it again, for normal compilers.

Of course, you can do all those optimizations for your native code compiler, but you'll be with me that, today at least (where SO many different processors, instruction sets, and architectures exist), it's quite rare to find it even for the tightest loops in a program.

The native code compiler can make optimizations for the architectrure you pass on the parameter, but not for "the one the program is running on"

pete:

:(

Jcl: I've had an encounter with C++/CLI these past few weeks, which was actually a positive surprise. It supports GC but doesn't force you to use it. Classes can be managed or unmanaged, and even the managed objects have deterministic destruction if they're allocated locally. And you can mix managed and unmanaged code, even easily calling external native libraries and APIs from the managed code with no intermediary layer save for a few simple declarations. The Java guys could learn a thing or two from Microsoft, apparently. But I still wouldn't write a game or a demo in it.

gasman: In theory, a static compiler can do almost anything that a JIT compiler can, but ultimately it would do this by including code that recompiles, rearranges, eliminates and inlines other code on the fly. So essentially it would have to embed a kind of JIT compiler into your code, and then it's not really winning ;). Plus there are still things that really wouldn't be possible with the JIT functionality tied to the release code (like supporting future CPU instruction sets via updates to the runtime system.)

But it's also true that outside of benchmarks carefully engineered by JIT advocates, native code still beats bytecode by something like an order of magnitude.

doom, I used to have an interactive commercial 3D application (for VJ'ing) wrote entirely in C# using OpenGL (Tao wrapper), and it worked just great. That was c# 1.0 and I wrote it back in 2003-2004...

Everything in .NET is so much better now... and although I don't do any realtime anymore, I'm sure it's, not only possible, but also very good at it :-)

Plus, writing UI code for it was SO easy :-)

But....i was working on my own Obj Loader :(

Can you draw lines now in WPF?

And, no. I'm not joking...

RTFM ;P

Rare: errr.. yes? :)

... and I don't like WPF, as a matter of fact, but that's personal... will more than probably have to end up using it, because Windows Forms seems to be quite stuck.

WPF != .NET anyway

True and sorry, I was talking about 3D, not 2D.

And yeah, there's ScreenSpaceLines, but they suck.
M$ can't be fucking serious about that, now can they?

Rare: you can make a D3DImage surface in WPF and write anything you could possible can with Direct3D to it, plus, you can use it that D3DImage as a WPF Brush, so you can use it basically everywhere (even composite with other stuff, or make a chromeless D3D window).

WPF is overly bloated (and pretty slow too), but it's probably the most flexible (windows) presentation library to date.

You could also use OpenGL, I know. Still I think it's pretty stupid. I though he was making a stupid joke or just had to RTFM when a workmate told me "There is no line primitive in the WPF 3D functions". I couldn't believe it...

He has never worked with D3D, but probably it is time to start...

Rare: there's no line (or even shapes) in c#'s windows forms components by default (you can import some old visual basic OCX and have them)... WPF is mostly targeted at doing UIs, not "rendering"... it's pretty high-level (you just have to look at the call-stack when doing a simple "mousedown" on a button)... it's just not targeted at making lines since standalone lines are not a common part of a normal, modern UI. You CAN do them... but it's not straightforward :-)

That's basically like saying "OpenGL can't do buttons by default"... you can make them, but it's not straightforward, since OpenGL is NOT targeted at making buttons. Same paradigm.

But you do agree with me that in a library (System.Windows.Media.Media3D) that provides 3D functions, can render polygons, has a 3D geometry class, lights and so on there should be a function to draw a friggin line in 3D?