Re:Common Pitfalls in Writing Lock-Free Algorithms
by pacaro on Wednesday March 27, 2013 @07:43PM
(#5452646)
Like the old carpenters adage "Measure twice, cut once"
Re:Common Pitfalls in Writing Lock-Free Algorithms
by niggler on Wednesday March 27, 2013 @08:25PM
(#5452762)
Like the old programmers adage "Days of programming save hours of planning"
Re:Common Pitfalls in Writing Lock-Free Algorithms
by tlarkworthy on Thursday March 28, 2013 @10:56AM
(#5455140)
We recently bought a laser cutter and realised that adage is based on the assumption that the cutting takes the longest time.
Now if we want a really good fit we do a binary search on the cut dimensions.
Our new laser cutter adage is "cut loads and don't bother measuring because it doesn't take into account the size of your cut"
Re:Common Pitfalls in Writing Lock-Free Algorithms
by stouset on Thursday March 28, 2013 @08:55PM
(#5458649)
The adage is based on the fact that you can't "undo" a cut too short. If you need a 6' board, and cut it to 5'10", you've probably just wasted a perfectly good piece of lumber.
Re:Common Pitfalls in Writing Lock-Free Algorithms
by pacaro on Thursday March 28, 2013 @07:52PM
(#5458411)
Also based on resource cost, you're probably not laser cutting a highly figured maple slab...
Re:Common Pitfalls in Writing Lock-Free Algorithms
by throwaway54-762 on Wednesday March 27, 2013 @09:02PM
(#5452870)
> In the author's example, the fastest implementation was actually _not_ lock-free, it merely used a better spinlock than std::mutex.
The author is also using gcc 4.6; perhaps different results would be obtained with gcc 4.8 or recent Clang. If you care enough to think about LFDS, measure measure measure =).
Any optimization should be measured. Otherwise how do you know if all your hard work is worth it? In the author's example, the fastest implementation was actually _not_ lock-free, it merely used a better spinlock than std::mutex.
It's a good idea to use existing implementations mostly so that you can measure and (hopefully without too much trouble) change out the implementation whenever you need to. Different hardware likely has different performance, so measure often!