Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why C++ for Unreal 4

forums.unrealengine.com

Post reply on HN
Print view View original

141–150 of 178 posts

Re: Why C++ for Unreal 4

#141

Post by munificent »

kansface wrote: post #135
munificent wrote: post #122

Earlier quoted context omitted.

> Was very glad to see them come to python and soon to mainstream javascript. I really need to get around to writing a blog post to explain this in detail since this misapprehension is endemic. Python and JavaScript do not have coroutines, they have generators. Lua has actual coroutines. The latter is dramatically more expressive than what you can do with what Python, JavaScript, and C# offer. This mistake drives me…

Py3000 added support for the "pass a generator" construct that you care about: http://simeonvisser.com/posts/python-3-using-yield-from-in-g... .

As far as I can tell, that's still just a little local syntactic sugar for making composing generators nicer. There's a still a fundamental distinction between generators and other functions.

Think of it like this. Let's say you have a chunk of code that you want to refactor out into a separate method. The usual way to do that is to pull it out into a separate method and then call it from the place where the code used to be inline.

In languages with coroutines, you can just do that, regardless of what's in that chunk of code. In Python, you have to think, "Oh, does this chunk of code contain a yield?" If so, you need to do a "yield from" the function you pulled out instead of a regular call.

It forces you to constantly be cognizant of and design around the split between normal code and generators.

Re: Why C++ for Unreal 4

#142

Post by munificent »

srean wrote: post #131
VikingCoder wrote: post #120

Earlier quoted context omitted.

I've been using threads to do co-operative multi-tasking, for a while now. Every place that I'm tempted to write an event-driven finite state machine, or something similar, I spawn a thread instead. I get to write synchronous code, which feels much more natural to me. For instance my actor, running in a thread, calls a function like advance(). That drops data into an object, and wakes up the main thread, and blocks.…

That is precisely the beauty of coroutines: your code can look like threaded code but you can get the performance of an event-loop. Put another way, with coroutines you get most of the advantages of an event loop but very few of its disadvantages. (You get concurrency only, not parallelism, well this is almost true). For cooperative multi-tasking, threads are unnecessarily resource hungry and wasteful. They hoard res…

> C exported pretty much every abstraction of the underlying instruction set, but not coroutines.

My hunch is that the designers of C would have said "goto" and "switch" cover the use case where you have a bunch of peer chunks of code that you want to freely bounce between.

Remember, at the time function calls were considered expensive, so not support full coroutines across function call boundaries may not have been on their minds as much.

Re: Why C++ for Unreal 4

#143

Post by JoeAltmaier »

pcwalton wrote: post #129
JoeAltmaier wrote: post #118

Earlier quoted context omitted.

Extraordinary claim- please elaborate. I'm working on 100's of thousands of lines of C++ code with a medium-sized team; memory issues are almost non-existent because of disciplines described above.

I've described this many times in the past, but here are a few things that modern C++ does nothing to protect against: * Iterator invalidation: if you destroy the contents of a container that you're iterating over, undefined behavior. This has resulted in actual security bugs in Firefox. std::vector v; v.push_back(MyObject); for (auto x : v) { v.clear(); x->whatever(); // UB } * "this" pointer invalidation: if you ca…

Right; stl sucks. So its work, but you can make ref-safe containers, even thread-safe ones. We do that; we do audio rendering with audio-chain editing on the fly, with no memory issues. It takes care, more care than other languages. But its far from unsolvable.

Re: Why C++ for Unreal 4

#144

Post by lobster_johnson »

beefsack wrote: post #38

It will be interesting if any major game engines pop up using Rust as the core language, or even Go. C++ has been the king of highly optimised game engines for so long, I can't help but feel it has become so entrenched in the industry that it will take something monumental to disrupt it.

I have high hopes for Nimrod [1] in that regard. Unlike Rust and Go, Nimrod is able to be almost as fast as C/C++ without sacrificing syntax; Nimrod's syntax often looks entirely like Python. For example, here's the example from the Nimrod home page:

    # compute average line length
    var count = 0
    var sum = 0

    for line in stdin.lines:
      count += 1
      sum += line.len

    echo "Average line length: ",
      if count > 0: sum / count else: 0
Type inference ensures that this uses efficient types internally, and is compiled to something very close to the efficiency of C. Here [2] is the generated C code, minus line tracing and stack trace frame generation. (Nimrod does things like bounds checking and overflow checking; without them, the program obviously becomes faster; the AddInt() function, for example, is replaced with a simple "+=".)

[1] http://nimrod-lang.org

[2] https://gist.github.com/atombender/f50e47c573f865d000ec

Re: Why C++ for Unreal 4

#145

Post by boulderdash »

srean wrote: post #131
VikingCoder wrote: post #120

Earlier quoted context omitted.

I've been using threads to do co-operative multi-tasking, for a while now. Every place that I'm tempted to write an event-driven finite state machine, or something similar, I spawn a thread instead. I get to write synchronous code, which feels much more natural to me. For instance my actor, running in a thread, calls a function like advance(). That drops data into an object, and wakes up the main thread, and blocks.…

That is precisely the beauty of coroutines: your code can look like threaded code but you can get the performance of an event-loop. Put another way, with coroutines you get most of the advantages of an event loop but very few of its disadvantages. (You get concurrency only, not parallelism, well this is almost true). For cooperative multi-tasking, threads are unnecessarily resource hungry and wasteful. They hoard res…

@srean - can you provide a link to the PDP support for coroutines? I would like to read more.

Re: Why C++ for Unreal 4

#146

Post by zanny »

pcwalton wrote: post #129
JoeAltmaier wrote: post #118

Earlier quoted context omitted.

Extraordinary claim- please elaborate. I'm working on 100's of thousands of lines of C++ code with a medium-sized team; memory issues are almost non-existent because of disciplines described above.

I've described this many times in the past, but here are a few things that modern C++ does nothing to protect against: * Iterator invalidation: if you destroy the contents of a container that you're iterating over, undefined behavior. This has resulted in actual security bugs in Firefox. std::vector v; v.push_back(MyObject); for (auto x : v) { v.clear(); x->whatever(); // UB } * "this" pointer invalidation: if you ca…

A lot of this just looks to be lacking const correctness. If you declared most of the mutable types const (and the use cases for a non-const unique_ptr are few) you can avoid most of these issues.

I think it is a valid criticism of the language that not all non-primitive types aren't implicitly const, though. But you could never implement that without colossal backwards compatibility breakage. Which I guess is fine, since you could just keep a code base an std= behind until you fixed it.

> Use after move: obvious. Undefined behavior.

This I don't have an answer to though. I've always disliked how this isn't a compiler error.

Re: Why C++ for Unreal 4

#147

Post by darylteo »

pjmlp wrote: post #19
danso wrote: post #12

> Developers seeking to take advantage of the engine's native C++ features end up dividing their code unnaturally between the script world and the C++ world, with significant development time lost in this Interop Hell. Replace "C++" with "JavaScript/client-side processing" and "script" with "server-side scripting" and I feel like this adequately describes web-development.

You also need to add the dark magic tribal dance of making CSS/HTML/JavaScript work in a coherent way across all target browsers in mobile, desktop, TV, settop boxes and whatever else... At least that is how it feels for guys like myself that lack designer skills.

I've yet to meet a designer that can do the above. Its very much a black magic regardless of who you are.

Re: Why C++ for Unreal 4

#148

Post by srean »

boulderdash wrote: post #145
srean wrote: post #131

Earlier quoted context omitted.

That is precisely the beauty of coroutines: your code can look like threaded code but you can get the performance of an event-loop. Put another way, with coroutines you get most of the advantages of an event loop but very few of its disadvantages. (You get concurrency only, not parallelism, well this is almost true). For cooperative multi-tasking, threads are unnecessarily resource hungry and wasteful. They hoard res…

@srean - can you provide a link to the PDP support for coroutines? I would like to read more.

By the time I got within touching distance of any computer the era of the PDPs were long over. I have learned from John Skaller that they could exchange control between two stack frames in a single assembly instruction. "Exchange Jump" is what I think it was called. You will have to search the assembly manual for PDP-11 for more. Wikipedia has some details http://en.wikipedia.org/wiki/Coroutine#Implementations_in_as... But I am sure there are HN readers who can speak with way more authority and exhaustiveness than the wikipedia page and can probably point find you a PDP-11 manual. I think you will find this thread interesting http://permalink.gmane.org/gmane.org.user-groups.linux.tolug...

Quoting the most interesting bits from that thread, (although I urge you to read the original):

  Of the many styles of subroutine calls on the PDP-10, JSP ac,addr is the fastest,
  as it's the only one that doesn't require a memory store.

  Its ISP is something like:

        ac = PC
        PC = effective address [addr in the usual case]

  The subroutine return, of course, is:

        JRST (ac)

  Here, the efective address is the contents of the register.

  The coroutine instruction combined the two:

        JSP ac,(ac)

  This essentially exchanged the PC with ac.

Re: Why C++ for Unreal 4

#149

Post by srean »

munificent wrote: post #142
srean wrote: post #131

Earlier quoted context omitted.

That is precisely the beauty of coroutines: your code can look like threaded code but you can get the performance of an event-loop. Put another way, with coroutines you get most of the advantages of an event loop but very few of its disadvantages. (You get concurrency only, not parallelism, well this is almost true). For cooperative multi-tasking, threads are unnecessarily resource hungry and wasteful. They hoard res…

> C exported pretty much every abstraction of the underlying instruction set, but not coroutines. My hunch is that the designers of C would have said "goto" and "switch" cover the use case where you have a bunch of peer chunks of code that you want to freely bounce between. Remember, at the time function calls were considered expensive, so not support full coroutines across function call boundaries may not have been…

Indeed, and thanks for the excellent commentary on coroutines, awaiting the blog post. I think another fact played into their decision: coroutines do not specify how they are to be scheduled, that leaves room for arbitrary policies. Not that C shied away from keeping things undefined.

Re: Why C++ for Unreal 4

#150

Post by Guthur »

jeremiep wrote: post #27
squidi wrote: post #9

Earlier quoted context omitted.

I love the irony of the contrast between this article and https://news.ycombinator.com/item?id=7584285 . Not that either are wrong, but it demonstrates the constant flux of the software world.

There's a world of difference between a web server handling each requests within ~1-30 ms and a game simulating the entire world made from thousands of entities under ~16ms. It is very possible to write games in high-level languages, but you will lose at least half the compute power of the machine by doing so. Note that unless you're writing a Gears of Wars, you don't really need such performance and productivity win…

"It is very possible to write games in high-level languages, but you will lose at least half the compute power of the machine by doing so."

Sounds definitive, interesting considering that in some cases languages like OCaml outperform C++.

C++ does not mystically provide good performance. Knowledge of algorithms and appropriate data structures are far more beneficial.

Does the coder know how to come up with something like http://en.wikipedia.org/wiki/Fast_inverse_square_root or the cost of a hash map verses indexed array lookup. These will win you far more than any language choice.

Post reply on HN