Planet Orange and Bronze

JM Ibanez: Quick Updates

Sun, 16 Nov 2008 16:10:49 +0000

Two things:

Work on tool that will be released as open source. I'm currently finishing up a component that we'll be releasing as open source in the coming week or so, once I get the bits cleaned up and checked in. It's a case of an "itch to scratch", and I'll be using it for a possible work project.
Another haircut. I got rid of my long hair today. That is all.

Discuss.

Dean Berris: IO Bound Application Redux (with Code Samples)

mikhailberis@gmail.com (Dean Michael) — Sat, 08 Nov 2008 14:11:16 +0000

In the previous article I gave a higher level overview of the recent foray I had into writing a data-parallel application that maximizes the parallelism that came with the solution to the problem. Now let me go into some of the details of how I made that happen.

The Active Object

First, I want to propose a simple framework for creating an active object which relies on Boost.Asio. Below is a code snippet for a template that allows you to use CRTP and build a simple Active Object implementation:

template <class Derived>

struct active {

  private:

    shared_ptr<io_service> queue;

    shared_ptr<io_service::work> sentinel;

    shared_ptr<thread> lifetime_thread;

  

  protected:

    active()

      : queue(new io_service()),

        sentinel(new io_service::work(*queue)),

        lifetime_thread(

          new thread(

            bind(&io_service::run, queue)

            )

          )

    {

      static_cast<Derived*>(this)->init();

    }



    ~active() {

      sentinel.reset();

      lifetime_thread->join();

      static_cast<Derived*>(this)->destroy();

    }



    void post(function<void()> f) {

      queue->post(f);

    }

};

The rationale for the above implementation is that we should be able to easily create active object implementations that have their own internal command queue and their own thread of execution. Above we rely on Boost.Thread (for the threading) and Boost.Function and Boost.Bind for the function object wrapping capabilities.

So let's say we use the above code to create our simple active hasher. The code to something like that is shown below:

   1: struct hasher : active<hasher> {

   2:   private:

   3:     int buckets_;

   4:     vector<shared_ptr<ofstream> > file_buckets;

   5:     string base_name;

6:

   7:     friend struct active<hasher>; // allow private access to base

8:

   9:     void init() { // required by active<>

  10:       for (int bucket = 0; bucket < buckets_; ++bucket)

  11:         file_buckets[bucket].reset(

  12:           new ofstream(

  13:             base_name + lexical_cast<string>(bucket)

  14:             )

  15:           );

  16:     };

17:

  18:     void destroy() { // required by active<>

  19:       vector<shared_ptr<ofstream> >().swap(file_buckets);

  20:     };

21:

  22:   public:

23:

  24:     hasher(int buckets, string const & base_name_) :

  25:       active<hasher>(),

  26:       buckets_(buckets),

  27:       file_buckets(buckets_),

  28:       base_name(base_name_)

  29:     { };

30:

  31:     void operator() (shared_ptr<vector<tuple<int, int, int> > > chunk) {

  32:       // schedule for later

  33:       active::post(

  34:         bind(&hash_impl, this, chunk)

  35:       );

  36:     }

37:

  38:   private:

  39:     void hash_impl(shared_ptr<vector<tuple<int, int, int> > > chunk) {

  40:       BOOST_FOREACH(tuple<int, int, int> const & entry, *chunk) {

  41:         // write entry to bucket, code not shown.

  42:       }

  43:     }

  44: };

Now we have an active hasher, that does its thing asynchronously on its own thread. When a chunk is encoded into the active hasher through the function operator overload (line 31) all we do is post a bound function `hash_impl` with the provided chunk. We can rest assured that hash_impl can and will be run in the lifetime thread -- currently there is only one lifetime thread so we don't have to worry about synchronization in the implementation of hash_impl.

The Chunk Reader

What we're now missing really is just the chunk reader. In implementing the Chunk Reader we use the "packaged task" idiom. In code, all we do is provide all the parameters the implementation will need at the constructor -- then the function operator overload when invoked doesn't take any parameters and just does whatever it needs to do given member variables. To make it more concrete, let me show you a simple implementation of the Chunk Reader:

   1: struct chunk_reader {

   2:   private:

   3:     size_t offset_;

   4:     size_t elements_;

   5:     string source_;

   6:     hasher & hash_;

   7:   public:

   8:     chunk_reader(string const & source,

   9:       size_t offset,

  10:       size_t elements,

  11:       hasher & hash_;

  12:       ):

  13:       offset_(offset),

  14:       elements_(elements),

  15:       source_(source)

  16:     { }

17:

  18:     void operator() () {

  19:       shared_ptr<vector<tuple<int, int, int> > > chunk;

  20:       // do what needs to be done here

  21:       // which is open the file, seek to

  22:       // offset_, and read the chunk, then:

  23:       // ...

  24:       hash_(chunk);

  25:     }

  26: };

From here, it's just then a matter of setting up the table. Notice that every instance of a chunk_reader needs a reference to a fully constructed hasher instance (line 11). This enforces that every thread hosting the invocation of the function operator overload implementation (line 18) will be able to invoke the hasher's function operator overload -- and thus enqueue the chunk that was gotten from the file.

Gluing Together

Now the missing part is really the set-up of how you actually create chunk reader threads that read concurrently from a file that defer the hashing to a single thread -- remember, in the original problem the reading is really what's taking too long (30GB read sequentially won't really be fast, but read concurrently can be very accomplished "quite easily") while the hashing is very quick. The simplest implementation is shown in the code fragment below:

hasher hash(buckets, "output-");

thread_group readers;

for (int thread_counter = 0; thread_counter < (processors * 2); ++thread_counter)

  readers.create_thread(

    chunk_reader("source_file", 

      thread_counter * size_of_chunk, 

      ( file_size / size_of_chunk ) / (processors * 2)),

      hash

      ) // packaged task

    ) // thread create

readers.join_all();

And there we have it. The approach taken here has been reduced to the parts that matter highlighting how we can leverage the available parallelism in a solution by properly decomposing the problem into sub-problems that get solved independent of others.

I hope this sheds more light and gives those reading insights about how you can possibly leverage multi-core architectures by writing code that exploits the concurrency in the solution and the available hardware.

Dean Berris: Leveling Up on IO Bound Parallel Applications

mikhailberis@gmail.com (Dean Michael) — Wed, 05 Nov 2008 13:21:32 +0000

Recently I had a chance to solve a simple problem which took forever to do with a single process. Here's the problem: I have a ~30GB file with structured binary data (a tuple of ints serialized as-is in memory) and I'm supposed to hash entries according to the first element of each contained tuple into multiple files.

Sounds simple and straightforward in a single-threaded application right? Right.

The problem then becomes the fact that the act of reading a tuple from disk to memory, deserializing it into memory, and then hashing it into the correct bucket is 90% I/O and 10% processing. Now imagine if you're on a multi-core machine (2 processors with 2 cores each having 2 hardware threads (in short 8 available processors)) and you're essentially using 10% of 1/8 the capacity of the machine. This is hardly satisfactory -- and not to mention painfully slow.

I then think to myself: this is an embarrassingly parallel problem, which I can solve by simply dividing the file up into a number of chunks, have one thread deal with one chunk of the file, then serialize the access to the files using an active object that maintains the streams that correspond to each "bucket" file. So I use Boost.Aisio's io_service object as a message/command queue for the actual writing/hashing of the tuple and read the file from many different threads to enqueue each tuple one by one. Problem solved.

Apparently not -- using htop I verify that the CPU's are filling up with red all over, and the queue is growing too fast for the active object to handle. This can only mean one thing: the process is more I/O bound than I thought.

One problem I was encountering was the granularity of each tuple having to be written to the buffer one at a time. The way the lifetime thread in the active object works is that it tries to lock a mutex on the queue -- while producer threads at the same time compete for the lock to add items to the queue -- once the consumer thread does get a tuple, it takes too long to write the tuple and before it knows what's happened it's competing for the lock again. Not only am I hitting an IO limit/cap of the hardware+OS combination, I was also introducing too much contention on the queue.

After pondering about it a little more, I thought to myself: why don't I batch up the tuples into a shared container that's in the heap and enqueue that chunk instead? That way the thread will maximize the IO time allotted to it and building the container instead of trying to compete for a lock all the time.

This little trick works -- by making the task running in the thread spend more time as much useful work as possible (reading the contents of the file and building the container) rather than making it compete all the time with other threads for a lock on the queue mutex, we maximize "productive" time and lessen "contention" time. This spells good performance and better hardware utilization.

So I thought running one thread per available hardware thread was going to do the trick -- apparently, I was wrong. Remember that the tasks were 90% IO and 10% "productive" work? This meant the threads kept waiting on IO rather than doing any/much useful work. More than half the time the threads were idling waiting for something to happen.

The solution seems to be to leverage the fact that IO waiting times dominate the computation. Running more threads per processor enables the OS to context switch away from a thread that's waiting for IO and move to a thread that is ready to process data. So if we have two threads with 9:1 IO to CPU work ratio sharing one hardware thread, we get 100% improvement on CPU utilization, and 50% reduction on waiting time -- of course we don't want to overdo it because it will introduce unnecessary overhead for too much context switching.

These series of optimizations allowed me to go from ~3 hours of processing a 30GB file (using a PERL script that did the hashing) down to ~1 hour of processing(with the 1:1 thread:processor ratio) down to ~30 minutes (with the 2:1 thread:processor ratio).

In the next post, I will dissect the code to reveal how I was able to achieve this kind of speedup on IO Bound applications.

Dean Berris: How about Meta-DSELs?

mikhailberis@gmail.com (Dean Michael) — Tue, 04 Nov 2008 14:53:18 +0000

With the recent release of Boost 1.37.0, the Boost C++ library now contains a Domain Specific Embedded Language (DSEL) framework in the form of Boost.Proto. No, this is NOT another library that just uses template metaprogramming tricks to do something really cool (like Boost.Spirit).

Imagine being able to create your own mini-language from within C++? Introducing Boost.Proto -- a DSEL for building your own DSEL. From the Boost.Proto documentation:

Proto is a framework for building Domain Specific Embedded Languages in C++. It provides tools for constructing, type-checking, transforming and executing expression templates ^[2] . More specifically, Proto provides:

An expression tree data structure.
A mechanism for giving expressions additional behaviors and members.
Operator overloads for building the tree from an expression.
Utilities for defining the grammar to which an expression must conform.
An extensible mechanism for immediately executing an expression template.
An extensible set of tree transformations to apply to expression trees.

There is something really weird with this library -- its intention is to allow practically anybody to create their own mini-language from within C++. It's no surprise that the Boost.Spirit library (and Boost.Phoenix library) will be using it in the next versions.

Not only is building DSELs in C++ possible, it's now made more accessible. So if you've always wanted to try building your own domain specific embedded language in C++, now is the time to start flexing those brain muscles and reading up on Boost.Proto.

Dean Berris: Boost C++ Library Patches (1.36.0)

mikhailberis@gmail.com (Dean Michael) — Mon, 03 Nov 2008 13:32:40 +0000

For those who have been having some trouble getting some libraries to compile nicely in Boost 1.36 using GCC 4.3.2, I have posted some issues (and associatively some patches) to Boost.Date_Time, Boost.Asio, and Boost.System to the Boost Trac installation. I've listed them down here with a short description of what the issue is and what the solution is (and where you can get the patch for Boost 1.36.0).

GCC 4.3.2 and stricter identifier restrictions

In the past versions of GCC, the following code would pose no problems:

namespace ns {

    template <class T>

    struct name {

    };



    name<int> name; // error here!

}

Now however, you'll get an error saying "declaration of 'name' changes the meaning of identifier 'name'". Apparently the fix is trivial which is to give the namespace qualified name:

namespace ns {

    template <class T>

    struct name {

    };



    ns::name<int> name; // no error anymore

}

There is some code in Boost.Date_Time (release 1.36.0) which has this problem. The issue is reported as Boost Trac issue #2465.

GCC 4.3.2 and stricter member construction requirements

Apparently GCC 4.3.2 has a more strict requirement on when a particular member variable is actually initialized or not -- especially when they are used as temporaries in a static function. I'm not sure if this is a compiler bug/feature, but nonetheless Boost.Date_Time's contrained_value template does not explicitly initialize the member 'value_' variable.

The trivial fix (which is to default-construct the member variable in the constructor) is available attached to issue #2463.

Boost.System's Missing 'get_posix_category'

In Boost 1.36.0, Boost.System's get_posix_category function had been removed. For strict backwards compatibility, it has to be put in to let older versions of libraries that use the function to link properly. This has been submitted as issue (with patches attached) #2461.

Boost.Asio's 'pipe_select_interrupter' warning

Still with GCC 4.3.2, discarded return values turn out to be warned against. There is a function in Boost.Asio's detail implementations that calls '::write(...)' and then ignores the return value -- which throws a warning and causes builds with -Werror to fail. The trivial patch is attached to the submitted issue #2462.

Caveats

These patches are submitted to the Boost community through the Trac Issue Trackings system. They have not yet been accepted by authors/maintainers at the time of this writing. Like the saying goes, use at your own risk.

Just as a reminder, these patches are to be applied to the Boost 1.36.0 release -- Boost 1.37.0 may have some of these issues addressed. If you find have questions about the patches (and don't want to post comments to the blog entry) please contact me directly through dean.berris@cplusplus-soup.com.

Dean Berris: Sea Change in Parallel Programming

mikhailberis@gmail.com (Dean Michael) — Sat, 01 Nov 2008 16:55:06 +0000

While going through my reading list, I found a very interesting entry about "Parallel Programming with Visual C++ 2010 CTP" by Marc Gregoire. Quoting the introduction:

The CTP build of Visual C++ 2010 includes a new library to help you write native parallel code. Writing parallel code is getting more and more important with the broad availability of quad-core CPUs at this time and the many-core CPUs that will appear in the coming years. I will only be talking about the new concurrency library for native code. Of course, writing parallel code has already been possible for a long time. However, you had to create and manage all threads by yourself and this could often be a complex task. Because of this, it requires quite a bit of time to parallelize a simple loop over multiple threads. The new native concurrency library makes this much easier.

Off the top of my head, I think this is a major development as far as C++ and parallel computing go. Bringing the tools and techniques (as well as idioms and patterns) of parallel computing closer to the developers allows for the start of the sea change in the way people approach programming in general. However, I would have to mention something that is subtly different in the way people approach parallelism now and for the foreseeable future.

Currently when you think about parallel computing/programming in C++ it usually includes the notion of threads and synchronization of access to data structures. If you come from a strictly imperative programming background this results in step-by-step changing of state and protecting memory from being changed in the wrong order. If you come from a functional programming background you'll have to think about how to decompose the solution into parts that result into something (or sends a message to something else) and reducing the result of these (potentially parallel-executed) tasks in the end.

The change in paradigm has something to do with the melding of these two approaches to parallel computing to yield a hybrid approach. Good thing with C++0x is that it's now easier to go a little functional while staying imperative in places that matter. To illustrate this, I'll post some C++0x code using Boost.Asio and Boost.Thread to show what I mean:

vector<int> sums;

vector<vector<int>> all_numbers; // initialized with contents...

mutex sums_mutex;

io_service queue;

shared_ptr<io_service::work> sentinel(new io_service::work(queue));

thread_group threads;

for (unsigned i=0u; i < processors; ++i)

    threads.create_thread(

        [&queue]() { queue.run(); }

        );



for_each(all_numbers.begin(), all_numbers.end(),

    [&sums, &queue, &sums_mutex](vector<int>& numbers) {

        queue.post(

            [&numbers, &sums_mutex]() {

                int sum = accumulate(numbers.begin(), numbers.end(), 0);

                scoped_lock lock(sums_mutex);

                sums.push_back(sum);

            });

    });


sentinel.reset();

threads.join_all();

Here we are mixing the use of mutexes (an inherently threading-specific construct) with lambdas (a functional programming idiom) to produce a highly concurrent way of computing the sums of a vector of vectors. What we're seeing here is a self-load balancing solution that makes each thread as busy as possible while only synchronizing on the modification of the sums vector.

One other thing to note here is that there are emerging patterns of parallelism in "chunked" or "task-based" concurrency:

function parallelized_computation(...) {

    // Initialize data structures

    // Set up the worker pool

    // Schedule computations

    // Wait on worker pool to complete

};

So while there are many models to concurrent/parallel computing, the basic building block is decomposition of the computation into units that can happen simultaneously. The details though, is where the complexity usually lies.

Microsoft has decided to deal with concurrent/parallel computing with the Parallel Pattern Library among other concurrent programming goodies that's already available in the Micrsoft Visual C++ 2010 Community Technology Preview (CTP). A good thing with this approach is that it plays very well with the next version of the upcoming C++0x standard (which is now in working draft form, so that means there won't be much changing between now and when the standard gets ratified).

The GNU Compiler Collection deals with parallelism at a lower level with parallel versions of the STL algorithms with OpenMP annotations in the implementation level. This spells good news to those who want to play with an open source version without needing additional infrastructure to leverage parallelism for applications. GCC 4.3.2 also already has partial support for C++0x features (which can be enabled by the -std=c++0x compiler flag).

Intel already has the Threading Building Blocks library (also open source) which provides lots of useful multi-threaded programming constructs for current compilers. I personally am not sure whether the Intel C++ compiler already has support for C++0x but I am not going to be surprised if they're already near getting a release out that does support newer language features.

Getting back into the topic of the sea change, it almost seems to be inevitable that parallel computing will play a major role in the further evolution of both the C++ programming language as well as application development in general. There is definitely a lot of interest in building better tools and better toolkits not only from the customer standpoint (people want programs they use to get faster as they buy better hardware to run it on) but also the developer standpoint (not using 100% CPU to get the job done faster almost always seems to be one of the best occupations out there).

And from where I'm looking, it seems like the future ahead is definitely bright.

Dean Berris: Cache Friendliness and Concurrency

mikhailberis@gmail.com (Dean Michael) — Fri, 31 Oct 2008 08:45:49 +0000

Herb Sutter had his article about addressing "the general problem of supporting multiple producers and multiple consumers with as much concurrency as possible." at Dr. Dobb's Journal earlier and I find a few things really interesting with the approach he's taken to leverage concurrency more by playing nicely with the cache. I quote:

Fourth, we want to follow the advice that "if variables A and B are not protected by the same mutex and are liable to be used by two different threads, keep them on separate cache lines" to avoid false sharing or "ping-ponging" which limits scalability. [3] In this case, we want to add padding to ensure that different nodes (notably the first and last nodes), the first and last pointers into the list, and the producerLock and consumerLock variables are all on different cache lines.

from October 29, 2008 - Writing a Generalized Concurrent Queue

[3] refers to H. Sutter. "Maximize Locality, Minimize Contention" (DDJ, September 2008). Available online at http://ddj.com/architect/208200273.

What's interesting here is that in code, it looks a little funny (still from the same article):



template <typename T>

struct LowLockQueue {

private:

  struct Node {

    Node( T* val ) : value(val), next(nullptr) { }

    T* value;

    atomic<Node*> next;

    char pad[CACHE_LINE_SIZE - sizeof(T*)- sizeof(atomic<Node*>)];

  };

So aside from being a little wasteful all in all this code seems to make use more of the hardware capabilities and in turn makes it a very platform-specific approach. It would be nice to have a general utility -- perhaps a macro -- that's implemented to provide padding on a per-compiler/platform basis.

All in all the article is a good read and thinking about extracting as much concurrency and as little synchronization has possible makes me think should there be new idioms developed when concurrency-centric programming comes to C++? I'm guessing the future sure is looking very bright for C++ and parallel/concurrent computing and programming in general.

Dean Berris: Parallel Computing on the Desktop

mikhailberis@gmail.com (Dean Michael) — Thu, 30 Oct 2008 07:38:13 +0000

I was reading through my reading list and I stumbled upon this post by James Reinders (Intel) titled "on Processors, Cores and Hardware threads":

Imagine a system with two processors, each eight core, and two hardware threads. Such a machine will offer 32 hardware threads.

Now that's not hard to imagine on the server side -- but even though it sounds like a lot of hardware threads, the sad reality is that applications written today aren't designed specifically to work on more than one hardware thread. Considering that operating systems already leverage the available parallelism in these systems (allowing users to interact with many different applications possibly doing things in the background at the same time) "out of the box", it's a different thing for developing your own custom software solution. And this is even on the server side.

Now a desktop that has that many number of hardware threads available means we have to look at different ways of writing applications that will scale as the number of hardware threads increase (even if each hardware thread doesn't execute as fast as single processors do a couple of years ago maybe). That means it's no longer just alright for your game, spreadsheet application, word processor, image/video editing software, or integrated development environment to just run on a single thread and not take advantage of available hardware threads -- or the OS should be a little smarter in distributing which software thread gets mapped to which hardware thread.

More than ever knowledge in parallel computing idioms and multi-threading techniques and designs would be valuable -- and soon necessary. I just hope people will get caught up in the wave and start swimming sooner than later.

And I think it's more true now that "scaling" is the name of the game.

Dean Berris: Trying out New Layout

mikhailberis@gmail.com (Dean Michael) — Wed, 29 Oct 2008 13:52:41 +0000

I've decided to spice things up a little on the site by changing the theme to a more eye-friendly (I think) color scheme. The previous layout made the site a little too plain and clean cut with very little variation. Now I'm trying something out to help with the look and readability (I hope) of the new layout.

Let me know if you like the color scheme or whether you like the older layout/theme better. If you're reading the feed, I'm pretty sure the content shouldn't be too much affected as you read through your favorite RSS reader.

At any rate, drop by the site and let me know what you think about the new theme!

Dean Berris: Coarse-Grained Data-Parallel: Statistics

mikhailberis@gmail.com (Dean Michael) — Tue, 28 Oct 2008 10:09:59 +0000

This field of data-parallel programming/computation is a very active one, since apparently it's a very important one as well for a few reasons. These reasons are not trivial and by no means unique to the field. Some of these reasons are:

Much of business and research activities rely on timely and accurate results.
Results usually matter at scale -- the more data you have, the better results you usually get.
The more data you have to deal with, usually you have a pretty hard problem to solve.

These three reasons above are the basic driving forces for looking into higher performance solutions to considerably large problems. Having said this, when you have the combination of large amounts of data and the requirement for timely and accurate results, you usually look at being able to leverage what's available to the maximum. With the advent then of multi-core computers, you try and leverage the parallelism available with being able to use more than one processor to do a lot of things at virtually the same time.

Intel has the Summary Statistics Library which (according to this article):

Intel® Summary Statistics Library is a set of algorithms for parallel processing of multi-dimensional datasets. It contains functions for initial analysis of raw data which allow investigating structure of datasets and get their basic characteristics, estimates, and internal dependencies.

The potential problems with this solution are:

Proprietary license for the Intel Math Kernel Library.
Tuned for Intel machines using Intel compilers.
Close-sourced, hard to identify accuracy of implementation.

Another possible solution is to use the Boost.Accumulators framework. According to the documentation:

Boost.Accumulators is both a library for incremental statistical computation as well as an extensible framework for incremental calculation in general. The library deals primarily with the concept of an accumulator, which is a primitive computational entity that accepts data one sample at a time and maintains some internal state.

Given this, the problems with this when you want to do parallel computations are:

Each accumulator works in an incremental fashion -- deal with data points one at a time.
It's hard to parallelize because each accumulator maintains state that depends on a previous state.

Possible Approaches

There are two possible approaches to developing a data-parallel statistics implementation. Let's consider a simple problem: computing the mean of N numbers in parallel.

There are two parts to the computation of the mean:

Compute the sum of all the numbers (data points).
Divide the sum by the count of the numbers.

The first part can be done with a simple divide and conquer approach:

If you have M processors, divide the N numbers to M processors to be summed in sequence.
Aggregate the M sub-totals to come up with the total.

The second part can be done as a simple step.

This is by no means exciting, and if it were to be coded in C++ (using Boost.Asio and Boost.Thread) it may look a little something like this:

io_service pool;

shared_ptr<io_service::work> sentinel(new io_service::work(pool));

thread_group threads;

for (unsigned i=0; i < processors; ++i)

threads.create_thread(

    bind(io_service::run, &pool)

    );

vector<int>::iterator begin=numbers.begin();

vector<int>::iterator end = begin;

size_t chunk_size = numbers.size() / processors;

vector<int> sums;

mutex sums_mutex;

do {

advance(end, chunk_size);

pool.post(

    bind(

      sum_range, ref(sums), ref(sums_mutex), begin, end

      )

    );

} while (end != numbers.end());

sentinel.reset();

threads.join_all();

int total_sum = accumulate(sums.begin(), sums.end(), 0);

double average =

numeric_cast<double>(total_sum)

/ numeric_cast<double>(numbers.size())

;

The missing part from the above snippet is the sum_range function which actually adds the sub-ranges and then adds the data to the sums vector:

void sum_range(vector<int> & sums, mutex & sums_mutex, vector<int>::iterator begin, vector<int>::iterator end) {

int intermediary_sum = accumulate(begin, end, 0);

{ // new scope for scoped_lock

scoped_lock lock(sums_mutex);

sums.push_back(intermediary_sum);

}

};

This is really simple but you can imagine that a lot of computations when it comes to statistics involves performing operations on ranges of values and computing certain aspects of the data that seem important. This is just a starter, and you can imagine that larger chunks of data can be dealt with more quickly if you explore the parallelism available in the computations you're making.

Conclusions

By far I've shown one possible approach to converting something serial (computing the sum of numbers) into something parallel. Only by going parallel will serial algorithms be able to take advantage of the next wave of multi-core architectures that are already available today and that will only increase in the future.

In the next few articles I'll delve deeper into a different kind of parallelism: fine-grained parallelism. These kinds of "chunky" computations I've shown above leverage the number of available processors to still do serial computations. However, the kinds of computations for fine-grained parallel applications are way different where data items are dealt with on a more granular level.

This is part of a running series of posts regarding parallel computing and parallel programming. If you have questions regarding the material or the subject and you don't feel like posting them as comments, send the author an email through dean.berris@cplusplus-soup.com.

Christian Chiu: SQL Case Problem - Solved with an Alternative Query

christian.chiu@gmail.com (Xt) — Mon, 27 Oct 2008 13:06:57 +0000

Yes! I did it. I was able to have an alternative query (Thanks to paxi for the initial UNION idea). As you can see, the code is longer than the one I posted yesterday, but then it is able to display what I need... perfectly.

I have here 3 SELECT statements, 2 of which are under the main SELECT and are combined thru UNION.

To evaluate these 2 SELECT statements, the first one is for the debit while the other one is for the credit. You may notice that in the intended debit select, I added NULL AS CREDIT and in the credit select counterpart, I added NULL AS DEBIT. This is because the UNION syntax requires me to have the two SELECT statements return tables that are equivalent (Same column data types and order).

And the SQL Query:

SELECT ABS(debit) AS debit, ABS(credit) AS credit, title FROM

(

SELECT entry_account.balance AS debit, null AS credit, accounts.title, entry_account.entry_id

FROM (entry_account INNER JOIN accounts ON entry_account.account_id = accounts.id)

WHERE (accounts.normal_balance = 'D') AND (entry_account.balance >= 0) OR (accounts.normal_balance = 'C') AND (entry_account.balance < 0)

UNION

SELECT null AS debit, entry_account_1.balance AS credit, accounts_1.title, entry_account_1.entry_id

FROM (entry_account entry_account_1 INNER JOIN accounts accounts_1 ON entry_account_1.account_id = accounts_1.id)

WHERE (accounts_1.normal_balance = 'C') AND (entry_account_1.balance >= 0) OR (accounts_1.normal_balance = 'D') AND (entry_account_1.balance < 0)

) derivedtbl_1

WHERE (entry_id = ?)

sweet...

Christian Chiu: SQL Case Problem

christian.chiu@gmail.com (Xt) — Sat, 25 Oct 2008 16:45:03 +0000

SELECT (CASE WHEN entry_account.balance > 0 THEN entry_account.balance ELSE null END) AS debit, accounts.title

FROM ((entry_account INNER JOIN

accounts ON entry_account.account_id = accounts.id) INNER JOIN

entry ON entry_account.entry_id = entry.id)

WHERE (entry.id = ?)

Basically, the above code simply wants to put a value in the debit column if entry_account.balance is > 0 else NULL is appended. This is not exactly what my business logic is but I just have to make it simpler to actually get myself familiarized with the CASE syntax.

The problem is, it just doesn't work. I browsed a couple of code snippets and all of them don't give my an idea why my code is wrong.

Have to sleep now, I might just get the answer tomorrow.

Ealden Escanan: Yes, it's another post about Struts!

noreply@blogger.com (Ealden Escañan) — Tue, 21 Oct 2008 14:38:51 +0000

Last week, I was reminded why I can't easily escape Struts 1 hell, and more importantly why I probably wouldn't want to escape it, at least any time soon.

The former is a question of business value: the module is already working and there are other stories lined up that needs implementing. In our case, we have quite a bit of polish work left as we count down the days until the release. On the other hand, when you magically find time to actually do a re-implementation as with the latter it becomes a question if you'd actually like to go through one. There are probably more important things to do, like count grass. More so if the current implementation without safety harness or close to a lost cause code-wise.

That was last week.

This is mostly a rambling of sorts of the current situation of the web layer in my current project, as well as some realizations and steps to move forward. This is also an excuse to blog again haha. Migration is definitely no going to happen overnight. The trick now is to migrate in stages: slowly pay off the technical debt until it's something that we can live with. Some steps I came up with that I should write down before I forget them:

Make use of Struts 2's compatibility mode for Struts 1 Actions. Migrating to Struts 2 is a combination of migrating the Actions and more importantly the views. These two steps normally should be done at the same time, but if it's possible to do just one that should reduce the complexity of migration.
Upgrade to a newer Struts 1 version. We are currently at 1.2.8 and I believe Struts 2 needs at least Struts 1 Actions at 1.3.5 to be able to use them. We used to have a base class for all Actions that overrode execute() in Struts 1's Action class to implement a MappingDispatchAction-like functionality (but poorly) and this made upgrading difficult. We were able to remove this a few months back and instead use MappingDispatchAction so this should be doable.
Test and code cleanup. We came up with a testing framework for Struts 1 Actions that, while involved and highly coupled to Struts and web technologies, offered a quick and simple way to test Struts 1 Actions. Should be helpful to capture the current behavior so the Action classes can be refactored safely. There are more advanced techniques in working with legacy code but I am not yet familiar with them.
Get XDoclet out. We have model-derived ActionForms using XDoclet and I've developed this annoyance for it as its "annotations" are too fragile. I figured having ActionForms coded gives more control and more flexibility than having them generated.

Jan Alonzo: catching up

Thu, 16 Oct 2008 10:14:28 +0000

Life’s been catching up with me lately as you can see from the number of posts I’ve written this year. Work’s been in full swing plus other company demands that you have to do outside of work hours. There’s also my studies which sometimes can be frustrating, not because it’s difficult, but because analysis and doing paperwork (i.e. assignments) can be really time consuming. And then outside of those two, I try to contribute to WebKit/Gtk as much as I can, even when sometimes it’s all drudgery commit other people’s patch kind of work (someone’s gotta commit those right?). But anyway, it’s all good. Learning and challenging myself is always, well, a challenge. Where does one find the time to do all the things they wanna do?

Joe Ledesma: O&B Library

noreply@blogger.com (City Farmer) — Tue, 14 Oct 2008 18:28:43 +0000

What i like about working in O&B is that we have a comprehensive library. Our CEO bulk orders books every now and then to add to the growing library. The books that we have covers a broad domain, from technical books, PMBA books and even up to project domains like insurance, accounting, stocks and a lot more. I think that a library like this is a good investment in any company. First, it is a good and always available resource for accurate and comprehensive information to aid our work. Second, It creates a culture of learning inside the company. Lastly, it can be a source of inspiration for people to broaden their knowledge and explore other things that they don't know when they browse the comprehensive title listing in the library.

Reading a physical paper and ink book is an entirely different experience than reading an electronic copy of a book. It is easier to read and much more convenient in terms of time and location constraints. Having many copies per title is also a good idea because a group of people can read the same books and have discuss what they have learned from the books. In a way, discussing lessons learned and discussing various subject matters can also be seen as some sort of informal training to widen the knowledge of an individual.

Recently, there are a lot of new additions to the Onb library. Personally, i have only read a few books from the library mainly PMBA books and a few self help books. Right now, i'm reading "Skills for New Managers" from the new batch, It's an interesting book and by the way its written, the information is easy to absorb. There are other interesting titles that i have seen in the new batch of books and i hope to read some during the coming holidays.

Calen Legaspi: Current Readings

noreply@blogger.com (Calen Martin D. Legaspi) — Sat, 11 Oct 2008 22:24:45 +0000

I'm currently reading Balanced Scorecard, Step-by-Step, by Paul Niven. The Balanced Scorecard is one of the most important management tools of the past century. It's about identifying the key metrics in your company from every perspective, not just financial. I'm developing the O&B's Balanced Scorecard as I read it.

Next on my reading list is Beyond Budgeting, by Hope and Fraser.

Tommy Lim: Learning buffet

noreply@blogger.com (Tommy) — Fri, 10 Oct 2008 16:29:19 +0000

Calen says to capitalize on learning experiences. From the start I planned on making a code generator for the project. In addition to making it less tedious and more interesting to work, I was also anticipating the benefits that it could bring to round 2. So I did despite the inevitability of taking longer to finish than I would have otherwise. So aside from finishing (well practically done

Charo Nuguid: The challenges of recording a Skype call

Sun, 28 Sep 2008 15:34:56 +0000

Recently I received an email from the community manager of Box.Net. He wanted to talk to me about their product. I didn't know how he came upon my blog and why he decided to contact me to talk about Box.Net. Perhaps it was because of my recent post about DropBox. Nevertheless, I thought it would be great to know more about his product.

But this post isn't about that interview. Actually it's about the challenges I went through in preparation for the interview. You see, the community manager wanted us to talk about their product. By talk I would think he wanted to contact me via Skype. And that's when my interesting journey started. READ MORE ABOUT IT »

Calen Legaspi: The 2 Secrets of a Successful Software Consulting Company

noreply@blogger.com (Calen Martin D. Legaspi) — Fri, 26 Sep 2008 01:50:12 +0000

Seems a lot of software consulting companies don't get it, so we'll give away our "secret". There's two keys to a successful consulting company:

Recruitment
Training

Some companies try to replace #1 with more of #2. They settle for second-string or third-string recruits and hope that spending enough money on training will be enough. This is the approach I see with a lot of the bigger companies. Let me tell you right now that by our own experience (and we're damn good trainers), all the training in the world won't arm an under-talented person with the decision-making and problem-solving ability that he/she needs in the project. Furthermore, given the pace of change in software development, you need people who can train themselves, otherwise it's a monumental effort to keep their skills relevant.

Some companies, particularly the smaller ones, try to replace #2 with more of #1. This is better than the first alternative, since good recruits, while expensive, can usually figure things out by themselves. The problem is, as you scale out, it's hard to find people who have both the talent and experience not to screw up on the job. I'm not just talking about more expensive salaries, I mean that even if you had all the money in the world there's just not enough of them out there! So you start recruiting talented people who haven't had much experience yet, and you hope they'll learn on the job. "After all", many developers-turned-entrepreneurs think, "I learned on the job as well, and look how I turned out." But these entrepreneurs forget all the screw-ups they made while learning on the job, and they don't know how much these screw-ups cost the company they used to work for, in terms of lost confidence from clients, re-done work, etc. So now, these talented but raw kids in your company will be learning from their own screw-ups, which you have to pay for.

So that's it really. Recruit and train. And retain. Okay, that's 3 secrets.

By the way, O&B is looking for partner consulting companies both to subcontract work to, and to expand to new markets. We're more than willing to share our recruitment, training and retention tactics to any company that we partner with.

Charo Nuguid: One DropBox to rule them all!

Mon, 22 Sep 2008 01:07:39 +0000

Having a laptop and a netbook has left me with a slight problem on file synchronization. For a while I was wondering what cross-platform app I could use to make sure the needed files on both computers stay the same. I've gotten used to opening the netbook to write my blog notes whereever I am. But when it comes to actually posting them on my blog, I find it much easier to do that from my laptop. I found out about a neat program courtesy Rom Feria though which allows me to sync files without having to use USB storage. The added plus: I can access stuff online too! READ MORE ABOUT IT »