Next release

Topics: Rawr.Base
Jun 30, 2010 at 4:23 PM

Would it be possible to release the next one relatively fast? I kinda destroyed the Combat tree in .19 and fixed this now.

Coordinator
Jun 30, 2010 at 5:13 PM
I could use a new release as well. I had a bad performance regression in .19 on top of Moonkin's already bottom-of-the-pile performance. All of that should be fixed now.
Coordinator
Jun 30, 2010 at 5:45 PM
I'll try to fix a few of the items that were acting up in the last build this evening, though it maybe later than sooner (since I just recently bought a new i7 with motherboard, so I would like to install that before raid tonight.
Developer
Jun 30, 2010 at 6:34 PM

The DPSWarr ArP issue kind of begs a new release too but I'd rather wait a tick to see if the fury optimize issue can be looked at by Ebs.

Developer
Jun 30, 2010 at 8:48 PM
I, too, would like to see a new release, as I did work on the Ruby Sanctum trinkets today, implementing the caster dps trinket, fixing the healing trinket, and making the tank trinket work in ProtPaladin.
Coordinator
Jun 30, 2010 at 9:03 PM

Lets plan for Saturday. So check in by Sat morning, please.

Jun 30, 2010 at 11:01 PM
dopefish wrote:
I had a bad performance regression in .19 on top of Moonkin's already bottom-of-the-pile performance.

Is it any worse than Warlock's performance?  It's pretty slow now-a-days.  I tried what I thought would be a huge improvement, before moving on to finer performance details, but instead it made it worse :(.

Developer
Jun 30, 2010 at 11:15 PM

WTB Performance Analysis (Analysises? Analysisses? Analysi?) for each model and the top 3-5 most performance intensive functions listed in a standard calculation. Then we can discuss ways to make those functions more performant. However we might want to move that to a new thread.

Developer
Jul 1, 2010 at 9:52 AM
Edited Jul 1, 2010 at 9:52 AM
Jothay wrote:

WTB Performance Analysis (Analysises? Analysisses? Analysi?) for each model and the top 3-5 most performance intensive functions listed in a standard calculation. Then we can discuss ways to make those functions more performant. However we might want to move that to a new thread.

 reported for anal spam :)

Developer
Jul 1, 2010 at 10:01 AM

Ret has a performance issue with haste.  Each discrete value of haste causing the calculation of a new ability usage table. (cached in memory per value of haste).

And 2T10 causing a large (variable) number of calculations of ability usage tables for each discrete value of haste. (and I don't even understand the reasoning/math behind why it's doing things like this).

 

Last few weeks I've been working on a linear optimisation approach to calcualting the ability usage table, and while it looked great on paper and worked a charm (and fast) on the LO engine used in my company, it seems to be performing awfull in performance on C# .NET  Still working on it

Coordinator
Jul 1, 2010 at 8:22 PM
Edited Jul 1, 2010 at 8:24 PM

Can you elaborate a bit what kind of linear optimisation you're doing and how you're doing it in C#? I'm asking because Mage model is more or less a large LP solver and if you need something similar I could transfer some of it to the Base.

Developer
Jul 2, 2010 at 11:34 AM

The basics behind it...  you feed the LO engine a possible solution (in my case, hit each ability once, then wait for everything to come off cd, and repeat). And let it optimize this solution. Specifically, squeeze more abilities into the time constraint.

The results I'm getting from the LO engine are identical to the sim ret is doing now (without 2T10). With a minor tweak to the rules, I can even turn the jagged haste curve into a smoothed out curve.  The nice part is that the LO solver can handle 2T10 while only adding a very small amount of calculation time. Whereas the ret sim now makes 2T10 take 10-15 more time than a non 2T10 setup.

The LO engine finds the result just a bit faster than the ret sim does now. But that LO engine is highly tuned C++ code.
I translated a part of the LO engine to a C# class, and compared performance to just using that same part in the LO engine.
Extrapolating the result, translated to C#, the LO solver would end up being a factor 50+ times slower than the already slow 2T10 sim.  From what I can see, the vast majority of time is being wasted in the .NET memory allocator and garbage collector.  The C++ code uses a hand crafted assembler and multi thread aware class purpose allocator/deallocator and barely spends any time in memory management, even though it's doing tons of new/delete's.

It was an interesting experiment, but I'm going to have to cancel this line of thought.

 

I'll try poking you on MSN over the weekend to talk about this and have a see if your mage LP might do the trick.

 

Coordinator
Jul 2, 2010 at 6:38 PM

If C# is ever 50x slower than C++, it means you're doing something different/wrong in the C#. Feel free to ask us for help on optimizing that.

Editor
Jul 5, 2010 at 8:12 AM

Re: Build?

Developer
Jul 5, 2010 at 1:11 PM
Astrylian wrote:

If C# is ever 50x slower than C++, it means you're doing something different/wrong in the C#. Feel free to ask us for help on optimizing that.

It's more a matter that there's no way to work around the memory manager, which is where the major speed is to be gained.
If I disable the special allocator/deallocator in the C++ code, and let it use the regular new/delete's, it slows down by a factor 7-10.  There's some more 'tricks' that have been used in the C++ code that have no equivalent in C# which if I disable those, bring the speed down even more.

But someone at work pointed out a flaw in my approach to begin with.  I was trying to LO a sim. not trying to LO a system. I get the results I want, but they're the same as the sim, so I could just as well use the sim itself, which is always going to be faster.

 

Jul 28, 2010 at 10:25 PM

Sorry for dragging up the old post but I know how y'all dislike discussion board clutter.

With several of the performance/optimization issues resolved and the Boss handler updates, I was wondering if a new release is coming soon. In the Issue Tracker there was a comment about releasing .21 on Monday but its now Wednesday and nothing new. All of your hard work is appreciated and I am looking forward to the improvements in both the Rawr2 and Rawr3 programs.

Editor
Jul 29, 2010 at 3:07 AM

We actually have an internal Developer discussion on the very subject.  Just getting all of our ducks in a row, or whatever.  You can expect a new release build extremely soon (within the next few days).

Coordinator
Jul 29, 2010 at 3:31 AM
Yeah, I tried to release .21 on Mon, and just wasn't able to. Same on Tue. Trying again tonight.
Coordinator
Jul 29, 2010 at 9:21 AM

...And tonight's attempt failed too. Trying again tomorrow night, sorry guys.

Editor
Jul 29, 2010 at 9:44 AM
Heh.
Developer
Jul 29, 2010 at 4:10 PM
Astrylian wrote:

...And tonight's attempt failed too. Trying again tomorrow night, sorry guys.

 Translation: I'm trying to beat my friends at SC2.

Coordinator
Jul 29, 2010 at 4:16 PM
Which reminds me, I really need to get going with the story mode. I'm only 7 missions into the storyline....
Developer
Jul 29, 2010 at 4:35 PM
I completed the campaign last night, now to go back for some achievements I missed
Developer
Jul 29, 2010 at 5:18 PM
Curses for being on business travel. I only just finished downloading and installing SC2.
Coordinator
Jul 29, 2010 at 5:39 PM

Haven't even bought SC2. So no, that's not it.

Coordinator
Jul 29, 2010 at 5:40 PM

I've been weaving missions in between raids, but tonight I've specifically set aside for focusing on one thing: STARCRAFT.  Sorry guild, raid progression can wait, I've got Zerg to slaughter.

Coordinator
Jul 29, 2010 at 6:17 PM

Meh our guild has already felt the Starcraft syndrome. Canceled Monday's raid because of people attending the Midnight release and yesterday's raid was cut short early (only did Halion 25 on normal and didn't attempt Lich King 25 HM attempts) because of lack of people playing Starcraft.

Editor
Jul 30, 2010 at 12:44 AM

Tuesday's raid was completely canceled (which was fine for me, as I wasn't around anyways - it was my 21st BDay!)  Wednesday, we have everyone sign on, but as soon as raid time comes, we get an announcement that we're nixing raid for the night.  Ugh.  If we're not raiding, just tell us beforehand, so I don't block off the night to raiding.  Thanks, guys.  :/

Jul 30, 2010 at 4:32 AM

Try being specifically recruited only to find out your second (sometimes even third ) string blocking off the time several nights each week (just in case), then having to try to find a PuG over the weekend.

Developer
Jul 30, 2010 at 4:55 AM

My guild's attendance has been even, if not slightly up, from before SC2's release.  Only one person I'm aware of has been playing SC2, and he has been raiding this week.

Editor
Jul 30, 2010 at 5:10 AM

Make that three days in a row of no raiding, though this third day has less to do with SCII than with a confluence of standard MIAs.  :P

Developer
Aug 2, 2010 at 1:57 PM

No chance at SC2 here.   Got my WOW beta key, so whatever bits of free time I have, are gonna go into that :)

Aug 9, 2010 at 12:28 AM

.21 made the Muti rogue pretty much unusable, which seems to be fix'd on the Source Code (go Fes!), but I guess fixing one model isn't reason enough to make a whole new release so soon?