high_scalability high_scalability-2008 high_scalability-2008-462 knowledge-graph by maker-knowledge-mining

462 high scalability-2008-12-06-Paper: Real-world Concurrency


meta infos for this blog

Source: html

Introduction: An excellent article by Bryan Cantrill and Jeff Bonwick on how to write multi-threaded code. With more processors and no magic bullet solution for how to use them, knowing how to write multiprocessor code that doesn't screw up your system is still a valuable skill. Some topics: Know your cold paths from your hot paths. Intuition is frequently wrong—be data intensive. Know when—and when not—to break up a lock. Be wary of readers/writer locks. Consider per-CPU locking. Know when to broadcast—and when to signal. Learn to debug postmortem. Design your systems to be composable. Don't use a semaphore where a mutex would suffice. Consider memory retiring to implement per-chain hash-table locks. Be aware of false sharing. Consider using nonblocking synchronization routines to monitor contention. When reacquiring locks, consider using generation counts to detect state change. Use wait- and lock-free structures only if you absolutely must. Prepare for the th


Summary: the most important sentenses genereted by tfidf model

sentIndex sentText sentNum sentScore

1 An excellent article by Bryan Cantrill and Jeff Bonwick on how to write multi-threaded code. [sent-1, score-0.098]

2 With more processors and no magic bullet solution for how to use them, knowing how to write multiprocessor code that doesn't screw up your system is still a valuable skill. [sent-2, score-1.095]

3 Some topics: Know your cold paths from your hot paths. [sent-3, score-0.339]

4 Intuition is frequently wrong—be data intensive. [sent-4, score-0.103]

5 Don't use a semaphore where a mutex would suffice. [sent-11, score-0.362]

6 Consider memory retiring to implement per-chain hash-table locks. [sent-12, score-0.293]

7 Consider using nonblocking synchronization routines to monitor contention. [sent-14, score-0.592]

8 When reacquiring locks, consider using generation counts to detect state change. [sent-15, score-0.39]

9 Use wait- and lock-free structures only if you absolutely must. [sent-16, score-0.211]

10 Prepare for the thrill of victory—and the agony of defeat. [sent-17, score-0.221]

11 While I don't agree that code using locks can be made composable, this articles covers a lot of very useful nitty-gritty details that will up your expert rating a couple points. [sent-18, score-1.126]


similar blogs computed by tfidf model

tfidf for this blog:

wordName wordTfidf (topN-words)

[('retiring', 0.221), ('thrill', 0.221), ('wary', 0.221), ('locks', 0.215), ('bonwick', 0.207), ('cantrill', 0.207), ('multiprocessor', 0.207), ('nonblocking', 0.207), ('semaphore', 0.207), ('routines', 0.191), ('composable', 0.175), ('rating', 0.171), ('bryan', 0.171), ('screw', 0.165), ('mutex', 0.155), ('bullet', 0.147), ('threaded', 0.139), ('false', 0.136), ('paths', 0.127), ('debug', 0.125), ('expert', 0.122), ('cold', 0.122), ('synchronization', 0.122), ('counts', 0.119), ('agree', 0.118), ('absolutely', 0.117), ('detect', 0.115), ('aware', 0.112), ('jeff', 0.112), ('covers', 0.112), ('magic', 0.107), ('frequently', 0.103), ('knowing', 0.1), ('break', 0.1), ('couple', 0.1), ('valuable', 0.098), ('write', 0.098), ('topics', 0.098), ('processors', 0.097), ('structures', 0.094), ('hot', 0.09), ('generation', 0.083), ('articles', 0.08), ('code', 0.076), ('points', 0.075), ('consider', 0.073), ('monitor', 0.072), ('implement', 0.072), ('useful', 0.066), ('details', 0.066)]

similar blogs list:

simIndex simValue blogId blogTitle

same-blog 1 1.0000001 462 high scalability-2008-12-06-Paper: Real-world Concurrency

Introduction: An excellent article by Bryan Cantrill and Jeff Bonwick on how to write multi-threaded code. With more processors and no magic bullet solution for how to use them, knowing how to write multiprocessor code that doesn't screw up your system is still a valuable skill. Some topics: Know your cold paths from your hot paths. Intuition is frequently wrong—be data intensive. Know when—and when not—to break up a lock. Be wary of readers/writer locks. Consider per-CPU locking. Know when to broadcast—and when to signal. Learn to debug postmortem. Design your systems to be composable. Don't use a semaphore where a mutex would suffice. Consider memory retiring to implement per-chain hash-table locks. Be aware of false sharing. Consider using nonblocking synchronization routines to monitor contention. When reacquiring locks, consider using generation counts to detect state change. Use wait- and lock-free structures only if you absolutely must. Prepare for the th

2 0.090886623 1541 high scalability-2013-10-31-Paper: Everything You Always Wanted to Know About Synchronization but Were Afraid to Ask

Introduction: Awesome paper on how particular synchronization mechanisms scale on multi-core architectures:  Everything You Always Wanted to Know About Synchronization but Were Afraid to Ask . The goal is to pick a locking approach that doesn't degrade as the number of cores increase. Like everything else in life, that doesn't appear to be generically possible: None of the nine locking schemes we consider consistently outperforms any other one, on all target architectures or workloads. Strictly speaking, to seek optimality,  a lock algorithm should thus be selected based on the hardware platform and the expected workload .  Abstract: This paper presents the most exhaustive study of synchronization to date. We span multiple layers, from hardware cache-coherence protocols up to high-level concurrent software. We do so on different types architectures, from single-socket – uniform and nonuniform – to multi-socket – directory and broadcastbased – many-cores. We draw a set of observations t

3 0.080288433 459 high scalability-2008-12-03-Java World Interview on Scalability and Other Java Scalability Secrets

Introduction: OK, this interview is with me on Java scalability issues. I sound like a bigger idiot than I would like, but I suppose it could have been worse. The Java World folks were very nice and did a good job, so there’s no blame on them :-) The interview went an interesting direction, but there’s more I’d like add and I will do so here. Two major rules regarding Java and scalability have popped out at me: Java – It’s the platform stupid . Java the language isn’t the big win. What is the big win is the ecosystem building up around the JVM, libraries, and toolsets. Java – It’s the community stupid . A lot of creativity is being expended on leveraging the Java platform to meet scalability challenges. The amazing community that has built up around Java is pushing Java to the next level in almost every direction imaginable. The fecundity of the Java ecosystem can most readily be seen with the efforts to tame our multi-core future. There’s a multi-core crisis going in case you haven’t

4 0.07517492 735 high scalability-2009-11-01-Squeeze more performance from Parallelism

Introduction: In many posts, such as:  The Future of the Parallelism and its Challenges  I mentioned that synchronization the access to the shared resource is the major challenge to write parallel code. The synchronization and coordination take long time from the overall execution time, which reduce the benefits of the parallelism; the synchronization and coordination also reduce the scalability. There are many forms of synchronization and coordination, such as: Create Task object in frameworks such as: Microsoft TPL, Intel TDD, and Parallel Runtime Library. Create and enqueue task objects require synchronization that it’s takes long time especially if we create it into recursive work such as: Quick Sort algorithm. Synchronization the access to shared data. But there are a few techniques to avoid these issues, such as: Shared-Nothing, Actor Model, and Hyper Object (A.K.A. Combinable Object). Simply if we reduce the shared data by re-architect our code this will gives us a huge benefits

5 0.074266151 1346 high scalability-2012-10-24-Saving Cash Using Less Cache - 90% Savings in the Caching Tier

Introduction: In a paper delivered at HotCloud '12 by a group from CMU and Intel Labs,  Saving Cash by Using Less Cache  ( slides ,   pdf ), they show it may be possible to use less DRAM under low load conditions to save on operational costs. There are some issues with this idea, but in a give me more cache era, it could be an interesting source of cost savings for your product.  Caching is used to: Reduce load on the database. Reduce latency. Problem: RAM in the cloud is quite expensive. A third of costs can come from the caching tier. Solution:  Shrink your cache when the load is lower. Their work shows when the load drops below a certain point you can throw away 50% of your cache while still maintaining performance. A few popular items often account for most of your hits, implying can remove the cache for the long tail.  Use two tiers of servers, the Retiring Group, which is the group of servers you want to get rid of. The Primary Group is the group of servers you

6 0.071417369 77 high scalability-2007-08-30-Log Everything All the Time

7 0.069159918 1204 high scalability-2012-03-06-Ask For Forgiveness Programming - Or How We'll Program 1000 Cores

8 0.067145422 1425 high scalability-2013-03-18-Beyond Threads and Callbacks - Application Architecture Pros and Cons

9 0.061953921 734 high scalability-2009-10-30-Hot Scalabilty Links for October 30 2009

10 0.06143713 920 high scalability-2010-10-15-Troubles with Sharding - What can we learn from the Foursquare Incident?

11 0.058210831 1318 high scalability-2012-09-07-Stuff The Internet Says On Scalability For September 7, 2012

12 0.058152385 914 high scalability-2010-10-04-Paper: An Analysis of Linux Scalability to Many Cores

13 0.055150338 1339 high scalability-2012-10-12-Stuff The Internet Says On Scalability For October 12, 2012

14 0.053881653 1643 high scalability-2014-05-06-The Quest for Database Scale: the 1 M TPS challenge - Three Design Points and Five common Bottlenecks to avoid

15 0.053021591 1387 high scalability-2013-01-15-More Numbers Every Awesome Programmer Must Know

16 0.052531183 1527 high scalability-2013-10-04-Stuff The Internet Says On Scalability For October 4th, 2013

17 0.051738311 684 high scalability-2009-08-18-Real World Web: Performance & Scalability

18 0.050734509 1045 high scalability-2011-05-20-Stuff The Internet Says On Scalability For May 20, 2011

19 0.050669029 378 high scalability-2008-09-03-Some Facebook Secrets to Better Operations

20 0.050166901 1015 high scalability-2011-04-01-Stuff The Internet Says On Scalability For April 1, 2011


similar blogs computed by lsi model

lsi for this blog:

topicId topicWeight

[(0, 0.073), (1, 0.049), (2, -0.0), (3, 0.008), (4, 0.02), (5, 0.034), (6, 0.013), (7, 0.028), (8, -0.034), (9, -0.004), (10, -0.019), (11, -0.017), (12, 0.014), (13, 0.003), (14, -0.012), (15, -0.032), (16, 0.014), (17, -0.002), (18, -0.001), (19, -0.002), (20, 0.014), (21, -0.011), (22, -0.022), (23, 0.016), (24, -0.018), (25, -0.016), (26, 0.031), (27, 0.018), (28, 0.012), (29, 0.038), (30, -0.02), (31, 0.001), (32, 0.005), (33, 0.007), (34, -0.017), (35, 0.006), (36, 0.039), (37, 0.022), (38, 0.037), (39, 0.025), (40, 0.003), (41, 0.022), (42, -0.024), (43, 0.025), (44, -0.005), (45, 0.003), (46, 0.027), (47, 0.038), (48, -0.016), (49, 0.002)]

similar blogs list:

simIndex simValue blogId blogTitle

same-blog 1 0.91995984 462 high scalability-2008-12-06-Paper: Real-world Concurrency

Introduction: An excellent article by Bryan Cantrill and Jeff Bonwick on how to write multi-threaded code. With more processors and no magic bullet solution for how to use them, knowing how to write multiprocessor code that doesn't screw up your system is still a valuable skill. Some topics: Know your cold paths from your hot paths. Intuition is frequently wrong—be data intensive. Know when—and when not—to break up a lock. Be wary of readers/writer locks. Consider per-CPU locking. Know when to broadcast—and when to signal. Learn to debug postmortem. Design your systems to be composable. Don't use a semaphore where a mutex would suffice. Consider memory retiring to implement per-chain hash-table locks. Be aware of false sharing. Consider using nonblocking synchronization routines to monitor contention. When reacquiring locks, consider using generation counts to detect state change. Use wait- and lock-free structures only if you absolutely must. Prepare for the th

2 0.72749674 1462 high scalability-2013-05-22-Strategy: Stop Using Linked-Lists

Introduction: What data structure is more sacred than the link list? If we get rid of it what silly interview questions would we use instead? But not using linked-lists is exactly what Aater Suleman recommends in Should you ever use Linked-Lists? In The Secret To 10 Million Concurrent Connections one of the important strategies is not scribbling data all over memory via pointers because following pointers increases cache misses which reduces performance . And there’s nothing more iconic of pointers than the link list. Here are Aeter's reasons to be anti-linked-list: They reduce the benefit of out-of-order execution. They throw off hardware prefetching. They reduce DRAM and TLB locality. They cannot leverage SIMD. They are harder to send to GPUs. He also demolishes the pros of linked-lists, finding arrays a better option in almost every case. Good discussion in the comment section as not everyone agrees. Patrick Wyatt details how a linked-list threading bug repeated

3 0.68755502 735 high scalability-2009-11-01-Squeeze more performance from Parallelism

Introduction: In many posts, such as:  The Future of the Parallelism and its Challenges  I mentioned that synchronization the access to the shared resource is the major challenge to write parallel code. The synchronization and coordination take long time from the overall execution time, which reduce the benefits of the parallelism; the synchronization and coordination also reduce the scalability. There are many forms of synchronization and coordination, such as: Create Task object in frameworks such as: Microsoft TPL, Intel TDD, and Parallel Runtime Library. Create and enqueue task objects require synchronization that it’s takes long time especially if we create it into recursive work such as: Quick Sort algorithm. Synchronization the access to shared data. But there are a few techniques to avoid these issues, such as: Shared-Nothing, Actor Model, and Hyper Object (A.K.A. Combinable Object). Simply if we reduce the shared data by re-architect our code this will gives us a huge benefits

4 0.66752887 1455 high scalability-2013-05-10-Stuff The Internet Says On Scalability For May 10, 2013

Introduction: Hey, it's HighScalability time: ( In Thailand, they figured out how to solve the age-old queuing problem! )   Nanoscale : Plants IM Using Nanoscale Sound Waves; 100 petabytes : CERN data storage Quotable Quotes: Geoff Arnold : Arguably all interesting advances in computer science and software engineering occur when a resource that was previously scarce or expensive becomes cheap and plentiful. @jamesurquhart : "Complexity is a characteristic of the system, not of the parts in it." -Dekker @louisnorthmore : Scaling down - now that's scalability! @peakscale : Where distributed systems people retire to forget the madness: http://en.wikipedia.org/wiki/Antipaxos  @dozba : "The Linux Game Database" ... Well, at least they will never have scaling problems. Michael Widenius : There is no reason at all to use MySQL @steveloughran : Whenever someone says "unlimited scalability", ask if that exceeds the ber

5 0.64558017 510 high scalability-2009-02-09-Paper: Consensus Protocols: Two-Phase Commit

Introduction: Henry Robinson has created an excellent series of articles on consensus protocols. Henry starts with a very useful discussion of what all this talk about consensus really means: The consensus problem is the problem of getting a set of nodes in a distributed system to agree on something - it might be a value, a course of action or a decision. Achieving consensus allows a distributed system to act as a single entity, with every individual node aware of and in agreement with the actions of the whole of the network. In this article Henry tackles Two-Phase Commit, the protocol most databases use to arrive at a consensus for database writes. The article is very well written with lots of pretty and informative pictures. He did a really good job. In conclusion we learn 2PC is very efficient, a minimal number of messages are exchanged and latency is low. The problem is when a co-ordinator fails availability is dramatically reduced. This is why 2PC isn't generally used on highly distributed

6 0.64226043 1621 high scalability-2014-03-28-Stuff The Internet Says On Scalability For March 28th, 2014

7 0.63980865 1541 high scalability-2013-10-31-Paper: Everything You Always Wanted to Know About Synchronization but Were Afraid to Ask

8 0.63529849 1537 high scalability-2013-10-25-Stuff The Internet Says On Scalability For October 25th, 2013

9 0.63524997 1239 high scalability-2012-05-04-Stuff The Internet Says On Scalability For May 4, 2012

10 0.63519472 914 high scalability-2010-10-04-Paper: An Analysis of Linux Scalability to Many Cores

11 0.63156283 1204 high scalability-2012-03-06-Ask For Forgiveness Programming - Or How We'll Program 1000 Cores

12 0.63054979 1237 high scalability-2012-05-02-12 Ways to Increase Throughput by 32X and Reduce Latency by 20X

13 0.62747914 1447 high scalability-2013-04-26-Stuff The Internet Says On Scalability For April 26, 2013

14 0.62701327 636 high scalability-2009-06-23-Learn How to Exploit Multiple Cores for Better Performance and Scalability

15 0.61989945 1509 high scalability-2013-08-30-Stuff The Internet Says On Scalability For August 30, 2013

16 0.61664748 1436 high scalability-2013-04-05-Stuff The Internet Says On Scalability For April 5, 2013

17 0.61090326 1246 high scalability-2012-05-16-Big List of 20 Common Bottlenecks

18 0.6017437 826 high scalability-2010-05-12-The Rise of the Virtual Cellular Machines

19 0.59777713 844 high scalability-2010-06-18-Paper: The Declarative Imperative: Experiences and Conjectures in Distributed Logic

20 0.59716082 1297 high scalability-2012-08-03-Stuff The Internet Says On Scalability For August 3, 2012


similar blogs computed by lda model

lda for this blog:

topicId topicWeight

[(1, 0.034), (2, 0.177), (10, 0.077), (40, 0.087), (61, 0.022), (77, 0.037), (79, 0.07), (87, 0.338), (94, 0.047)]

similar blogs list:

simIndex simValue blogId blogTitle

1 0.91339886 394 high scalability-2008-09-25-HighScalability.com Rated 16th Best Blog for Development Managers

Introduction: Jurgen Appelo of Noop.nl asked for nominations for top blogs and then performed a sophisticated weighting of their popularity based on page range, trust authority, Alexa rank, Google hits, and number of comments. When all the results poured out of the blender HighScalability was ranked 16th. Not bad! Joel on Software was number one, of course. The next few were: 2) Coding Horror by Jeff Atwood 3) Seth's Blog by Seth Godin and 4) Paul Graham: Essays Paul Graham. All excellent blogs. Very cool.

same-blog 2 0.80495054 462 high scalability-2008-12-06-Paper: Real-world Concurrency

Introduction: An excellent article by Bryan Cantrill and Jeff Bonwick on how to write multi-threaded code. With more processors and no magic bullet solution for how to use them, knowing how to write multiprocessor code that doesn't screw up your system is still a valuable skill. Some topics: Know your cold paths from your hot paths. Intuition is frequently wrong—be data intensive. Know when—and when not—to break up a lock. Be wary of readers/writer locks. Consider per-CPU locking. Know when to broadcast—and when to signal. Learn to debug postmortem. Design your systems to be composable. Don't use a semaphore where a mutex would suffice. Consider memory retiring to implement per-chain hash-table locks. Be aware of false sharing. Consider using nonblocking synchronization routines to monitor contention. When reacquiring locks, consider using generation counts to detect state change. Use wait- and lock-free structures only if you absolutely must. Prepare for the th

3 0.71592534 1526 high scalability-2013-10-02-RFC 1925 - The Twelve (Timeless) Networking Truths

Introduction: The Twelve Networking Truths  is one of a long series of timeless truths documented in sacred  April Fools' RFC s. Though issued in 1996, it's no less true today. It's hard to pick a favorite because they are all good. But if I had to pick, it would be: Some things in life can never be fully appreciated nor understood unless experienced firsthand. As we grow comfortable behind garden walls, clutching gadgets like lifelines and ideologies like shields, empathy is the true social network.   Network Working Group R. Callon , Editor Request for Comments: 1925 IOOF Category: Informational 1 April 1996 The Twelve Networking Truths Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract Thi

4 0.71413386 499 high scalability-2009-01-22-Coming soon: better JRockit+Coherence integration

Introduction: At the Oracle Coherence Special Interest Group meeting today in London, Tomas Nilsson, the product manager for JRockit RT and JRockit Mission Control spoke about the future plans for JRockit and especially plans for improved Coherence JRockit integration.

5 0.68147039 1478 high scalability-2013-06-19-Paper: MegaPipe: A New Programming Interface for Scalable Network I-O

Introduction: The paper  MegaPipe: A New Programming Interface for Scalable Network I/O  ( video , slides ) hits the common theme that if you want to go faster you need a better car design, not just a better driver. So that's why the authors started with a clean-slate and designed a network API from the ground up with support for concurrent I/O, a requirement for achieving high performance while scaling to large numbers of connections per thread, multiple cores, etc.  What they created is MegaPipe, "a new network programming API for message-oriented workloads to avoid the performance issues of BSD Socket API." The result: MegaPipe outperforms baseline Linux between  29% (for long connections)  and  582% (for short connections) . MegaPipe improves the performance of a modified version of  memcached between 15% and 320% . For a workload based on real-world HTTP traces, MegaPipe boosts the throughput of  nginx by 75% . What's this most excellent and interesting paper about? Message-oriented netwo

6 0.61203593 1381 high scalability-2013-01-04-Stuff The Internet Says On Scalability For January 4, 2013

7 0.60595399 614 high scalability-2009-06-01-Guess How Many Users it Takes to Kill Your Site?

8 0.58435094 1548 high scalability-2013-11-13-Google: Multiplex Multiple Works Loads on Computers to Increase Machine Utilization and Save Money

9 0.55536562 1235 high scalability-2012-04-27-Stuff The Internet Says On Scalability For April 27, 2012

10 0.54199696 683 high scalability-2009-08-18-Hardware Architecture Example (geographical level mapping of servers)

11 0.52418166 353 high scalability-2008-07-20-Strategy: Front S3 with a Caching Proxy

12 0.51952028 330 high scalability-2008-05-27-Should Twitter be an All-You-Can-Eat Buffet or a Vending Machine?

13 0.51857883 1471 high scalability-2013-06-06-Paper: Memory Barriers: a Hardware View for Software Hackers

14 0.51658714 879 high scalability-2010-08-12-Think of Latency as a Pseudo-permanent Network Partition

15 0.51485896 1425 high scalability-2013-03-18-Beyond Threads and Callbacks - Application Architecture Pros and Cons

16 0.51373065 1419 high scalability-2013-03-07-It's a VM Wasteland - A Near Optimal Packing of VMs to Machines Reduces TCO by 22%

17 0.51285332 1207 high scalability-2012-03-12-Google: Taming the Long Latency Tail - When More Machines Equals Worse Results

18 0.51157737 482 high scalability-2009-01-04-Alternative Memcache Usage: A Highly Scalable, Highly Available, In-Memory Shard Index

19 0.51021063 1429 high scalability-2013-03-25-AppBackplane - A Framework for Supporting Multiple Application Architectures

20 0.50820816 1492 high scalability-2013-07-17-How do you create a 100th Monkey software development culture?