News for hackers. Stuff that matters.
Re:Teaching Concurrency (2009) [pdf] by TickleSteve on Thursday September 22, 2016 @02:41AM (#12554923)
if you are in an I/O bound situation, then yes, concurrency will allow you to exploit some parallelism.

Otherwise, no.

(and in general, people just throw concurrency at the problem instead of analysing whether they are in fact I/O bound or CPU bound).

(Downvoted why??)

Re:Teaching Concurrency (2009) [pdf] by gohrt on Thursday September 22, 2016 @03:47AM (#12555216)
you may have been downvoted for making an unsubstantiated claim that most people don't know when their CPU is running at 100%
Re:Teaching Concurrency (2009) [pdf] by TickleSteve on Thursday September 22, 2016 @04:18AM (#12555342)
...and that is true.

When was the last time you monitored what parts of your system were truly I/O bound and not just blocked on another task?

Re:Teaching Concurrency (2009) [pdf] by monix on Thursday September 22, 2016 @10:36AM (#12557051)
People that end up in a position to care about performance are using profilers and bechmarks. This is actually the first rule: don't guess, measure.

Of course it helps when the platform has the proper tools for it. I end up using JMH and YourKit Profiler weekly, because a memory or CPU leak can crash our process and we have pretty strict reliability requirements with a single server processing about 5000 events per second - not extremely demanding, but when it crashes, we can lose money, with the redundancy infrastructure being pretty new.

Re:Teaching Concurrency (2009) [pdf] by sidlls on Thursday September 22, 2016 @01:24PM (#12558477)
This very thing has occupied my day job for at least four months now. It happens when a pre-existing system one has to improve has lots of DB-heavy and compute-heavy operations commingled.
Re:Teaching Concurrency (2009) [pdf] by kod on Thursday September 22, 2016 @08:25AM (#12556295)
Yesterday?