IdTech 4, 15% frame rate increase through semiautomatic paralellization • Hacker News Board

Re: IdTech 4, 15% frame rate increase through semiautomatic paralellization

#21

Post by taligent » Tue, Oct 30, 2012, 9:55 PM UTC

jspthrowaway wrote: post #18

taligent wrote: post #17

Earlier quoted context omitted.

The only way you know if your product is imperfect is by other people constructively criticising it. But instead you would rather all of us stand around in a circle cheering them on about how wonderful it is and politely ignore any problems. Sounds like a guaranteed way to fail.

Dismissal is not constructive criticism. There's a sizable difference between "meh, nothing to see here" (which is the original comment in this thread) and "here's how this could be better".

Dismissal is absolutely constructive criticism if you're looking at it from a business perspective.

If the product does not provide a decent ROI then you are right to dismiss it.

Re: IdTech 4, 15% frame rate increase through semiautomatic paralellization

#22

Post by jspthrowaway » Tue, Oct 30, 2012, 9:56 PM UTC

taligent wrote: post #19

jspthrowaway wrote: post #10

Earlier quoted context omitted.

All of what you say is wise, but the engineer doesn't work for the studio and isn't on Doom 3's release timeline. He made the game's frame rate 15% faster of his own volition simply because he could . So it's wrapped in a sales pitch, oh well. "I see something I can improve, but I had better not improve it; were I to work at id, my time would probably be more valuably spent on other things." I wish you'd just back of…

> He made the game's frame rate 15% faster of his own volition simply because he could. This isn't some lone engineer's noble cause. This is a sales product demonstration. > Attitudes like yours hurt our industry as a whole. No it doesn't. People SHOULD be critical of demonstrations like these because they are rarely representative of real world behaviour.

People who have never used software should be critical of "here's what our software can do with inexperienced hands, maybe you'll do better"? I'd much rather default to giving benefit of the doubt than assuming everything sucks before I've even touched it. Reminded of people who say they don't like exotic food but have never eaten it.

I think the lowest opinion on the totem pole is one formed by assumptions (based upon personal experience with an area) used to reflect upon something from the hip. "I'm pretty versed in game development, and what these people are doing is stupid based on my world view."

Re: IdTech 4, 15% frame rate increase through semiautomatic paralellization

#23

Post by KaeseEs » Tue, Oct 30, 2012, 9:57 PM UTC

jspthrowaway wrote: post #13

randallu wrote: post #5

So looking at the patch: 1. The allocator was a bottleneck; wonder if tcmalloc would have done better? 2. Computing what to draw? (idInteraction) was reduced to a for-loop and parallelized 3. ... lots more pre-rendering stuff ... Unfortunately they didn't annotate the patch with the size of the win for any given change, or write up an analysis on what the changes were (I'm unfamiliar with idTech, too). If they got th…

glibc's malloc() is known to be lackluster under parallel workloads. Alternatives do perform better in certain circumstances, but profile before making the switch -- your situation might not be one of them. It's possible to inject tcmalloc into an executable using Linux's preloader, too, without recompiling[1]. [1]: http://gperftools.googlecode.com/svn/trunk/doc/heapprofile.h...

I'm quite surprised that idTech4 was using _any_ malloc implementation aside from the initial allocation of the memory pool that it would use for its actual runtime allocator.

Re: IdTech 4, 15% frame rate increase through semiautomatic paralellization

#24

Post by jblow » Tue, Oct 30, 2012, 10:00 PM UTC

kevingadd wrote: post #3

A 15% framerate increase from 3 weeks of work isn't particularly impressive. It would be more meaningful if the measurement was in terms of frametime (i.e. elapsed time per frame) since framerate is not linear. From looking at the patch (nice of them to provide it), it seems like most of the changes are putting mutexes around things to guard against simultaneous access and then parallelizing some loops. It seems to m…

This is not just middlebrow dismissal, it's outright wrong. In the AAA world we would love to spend only 3 weeks of an engineer's time to get a 15% speedup. Seriously, that is a great deal, it's like, where do I sign up?

However, it becomes substantially less impressive when you notice that you're using 2x or 4x the amount of processor hardware (2 or 4 cores) and only getting a 15% speedup. In a by-hand implementation that would be very disappointing.

If it were fully automated that would still be pretty valuable, but it appears that this isn't. So it seems to be of questionable utility.

Re: IdTech 4, 15% frame rate increase through semiautomatic paralellization

#25

Post by jspthrowaway » Tue, Oct 30, 2012, 10:19 PM UTC

KaeseEs wrote: post #20

jspthrowaway wrote: post #15

Earlier quoted context omitted.

I, like pg and hopefully other Hacker News readers, am pretty sick of every story about something cool being immediately derailed by a know-it-all in an industry dismissing the innovation as "not cool enough". pg calls it middlebrow dismissal[1]. Rather than being treated as an imperfect launching-off point for further innovation, everything has to be world-changing perfect to have a reasonably sane comments section.…

Another negative trend that's clearly happened in this thread is drive-by voting: all of your interlocutor's posts have negative points, whereas the only posts in the thread that deserved any downvotes were the initial post (the only legitimate instance of the poorly-named 'middlebrow dismissal' that I can see) and the one where you put words in his mouth at the end ("Oh, so they're liars now?"). Postulate: very few…

I didn't put words in his mouth, he wrote that they were lying to managers and possibly being deceptive. You also misquoted me, which is ironic given your criticism.

Your postulation is unwarranted, by the way, since my posts have been going up and down based upon their depth in the thread. The top comments have been upvoted more than the lower ones, and the lower ones have actually been muted somewhat. I would actually suggest that people are reading the thread and voting appropriately, and probably aren't making it deepest into the thread.

Your sweeping characterization of mindless Hacker News voters acting by whim is disconcerting, to say the least. That we're so fixated on the voting here when karma is absolutely worthless is equally annoying. I am, however, intrigued by the shift from very light gray back to legible that has taken place on his comments since the beginning of this meta discussion (starting with ww520's remark); there might be something to what you're saying, which is that people are acting based upon what others are saying -- that's troubling.

Re: IdTech 4, 15% frame rate increase through semiautomatic paralellization

#26

Post by jspthrowaway » Tue, Oct 30, 2012, 10:31 PM UTC

taligent wrote: post #21

jspthrowaway wrote: post #18

Earlier quoted context omitted.

Dismissal is not constructive criticism. There's a sizable difference between "meh, nothing to see here" (which is the original comment in this thread) and "here's how this could be better".

Dismissal is absolutely constructive criticism if you're looking at it from a business perspective. If the product does not provide a decent ROI then you are right to dismiss it.

Ruling out a product and dismissing it based on projected ROI is not criticism. That would be called "making a business decision," not providing constructive feedback.

Re: IdTech 4, 15% frame rate increase through semiautomatic paralellization

#27

Post by nitrogen » Tue, Oct 30, 2012, 10:52 PM UTC

jspthrowaway wrote: post #13

randallu wrote: post #5

So looking at the patch: 1. The allocator was a bottleneck; wonder if tcmalloc would have done better? 2. Computing what to draw? (idInteraction) was reduced to a for-loop and parallelized 3. ... lots more pre-rendering stuff ... Unfortunately they didn't annotate the patch with the size of the win for any given change, or write up an analysis on what the changes were (I'm unfamiliar with idTech, too). If they got th…

glibc's malloc() is known to be lackluster under parallel workloads. Alternatives do perform better in certain circumstances, but profile before making the switch -- your situation might not be one of them. It's possible to inject tcmalloc into an executable using Linux's preloader, too, without recompiling[1]. [1]: http://gperftools.googlecode.com/svn/trunk/doc/heapprofile.h...

Even under single-threaded applications, with a custom allocator that suits your workload, it's possible to get significant speed boosts over the system malloc. One of the assignments I enjoyed back in college was writing a memory allocator. By the time I was done optimizing (including replacing all structs with raw pointer arithmetic using #defines), IIRC I was getting over 10000 single-threaded allocations per second vs. ~3000 from malloc().

Re: IdTech 4, 15% frame rate increase through semiautomatic paralellization

#28

Post by FrankBooth » Tue, Oct 30, 2012, 11:01 PM UTC

jblow wrote: post #24

kevingadd wrote: post #3

A 15% framerate increase from 3 weeks of work isn't particularly impressive. It would be more meaningful if the measurement was in terms of frametime (i.e. elapsed time per frame) since framerate is not linear. From looking at the patch (nice of them to provide it), it seems like most of the changes are putting mutexes around things to guard against simultaneous access and then parallelizing some loops. It seems to m…

This is not just middlebrow dismissal, it's outright wrong. In the AAA world we would love to spend only 3 weeks of an engineer's time to get a 15% speedup. Seriously, that is a great deal, it's like, where do I sign up? However, it becomes substantially less impressive when you notice that you're using 2x or 4x the amount of processor hardware (2 or 4 cores) and only getting a 15% speedup. In a by-hand implementatio…

When were you in the AAA world, Jonathan?

Re: IdTech 4, 15% frame rate increase through semiautomatic paralellization

#29

Post by randallu » Tue, Oct 30, 2012, 11:15 PM UTC

randallu wrote: post #5

So looking at the patch: 1. The allocator was a bottleneck; wonder if tcmalloc would have done better? 2. Computing what to draw? (idInteraction) was reduced to a for-loop and parallelized 3. ... lots more pre-rendering stuff ... Unfortunately they didn't annotate the patch with the size of the win for any given change, or write up an analysis on what the changes were (I'm unfamiliar with idTech, too). If they got th…

Oh, so I just noticed the "Whitepaper" link, and that has lots more good info in (I wish the blog post was the whitepaper!).

So does Pareon depend on running an instrumented build? If so, wouldn't you need a sample data file (map, demo, whatever) that covers 100% of branches and dependencies in order to know for absolutely sure that there are no dependencies between code.

Could you make a huge SSA of the program and determine dependencies that way (more of a reality now that we have 64bit desktops and GCC has "whopr" and friends)?

Re: IdTech 4, 15% frame rate increase through semiautomatic paralellization

#30

Post by jblow » Tue, Oct 30, 2012, 11:24 PM UTC

FrankBooth wrote: post #28

jblow wrote: post #24

Earlier quoted context omitted.

This is not just middlebrow dismissal, it's outright wrong. In the AAA world we would love to spend only 3 weeks of an engineer's time to get a 15% speedup. Seriously, that is a great deal, it's like, where do I sign up? However, it becomes substantially less impressive when you notice that you're using 2x or 4x the amount of processor hardware (2 or 4 cores) and only getting a 15% speedup. In a by-hand implementatio…

When were you in the AAA world, Jonathan?

I did a lot of consulting / contract work at AAA companies between 2000-2005. "Parachute in and make the E3 demo work / implement some tough feature / etc". Sometimes it was less well-defined than that.