[llvm-commits] [cfe-commits] [PATCH][Review Request] EarlyCSE stack overflow - bugzilla 11794

Lenny Maiorani lenny at Colorado.EDU
Fri Jan 20 13:41:56 PST 2012


On Jan 20, 2012, at 1:29 PM, Jakob Stoklund Olesen wrote:

> 
> On Jan 20, 2012, at 11:21 AM, Andrew Trick wrote:
> 
>> On Jan 19, 2012, at 3:41 PM, Jakob Stoklund Olesen wrote:
>> 
>>> On Jan 19, 2012, at 1:41 PM, Lenny Maiorani wrote:
>>>> List: 92.473490 seconds
>>>> Stack: 15.575143 seconds
>>>> Deque: 9.129154 seconds
>>>> Deque iter insert: 7.384741 seconds
>>>> Vector: 13.387473 seconds
>> 
>> My stack (doing the same thing as deque iter insert):
>> accum = -12238
>> time = 63.691762 seconds
>> 
>> 
>> Deque iter insert:
>> accum = -12238
>> time = 67.037268 seconds
>> 
>> 
>> Deque:
>> accum = -12238
>> time = 84.097848 seconds
>> <stack-test.cpp>
>> 
>> Yay for simplicity and common sense. I don't think you need a benchmark to prove that one data structure access is faster than two of the same type of access.
>> 
>>> Thanks for taking the time to do this and actually posting numbers.
>> 
>> Thanks Lenny. I'd like to see more measurements in general. I just want to give Jakob a hard time for his faith in numbers.
> 
> You are both wrong, of course. Everybody knows that a vector is the best solution for this problem. ;-)
> 
> However, this is not about having faith in numbers. It's about thinking to produce them in the first place. This sentiment is far too rare: "Before I blindly stated that I thought std::stack or std::deque would be better, I decided I would verify this."
> 
> I though Lenny's numbers were odd, but I wanted him to fix the correctness problem first.
> 
> /jakob
> 

There is actually a real difference here. The difference is that when the std::stack or std::deque is being used, it is necessary to have 2 stacks or deques because there is no reverse iterator on DomTreeNode. I am trying to preserve the order of processing nodes so that there is not some case where the behavior changes. If the order does not need to be preserved, then clearly it can be further optimized.

I still need to take a look at Jakob's other review comment.

-Lenny





More information about the llvm-commits mailing list