Moment of Inertia [ Hiran ]

gcc 4.5.1

GCC 4.5.1 was released last week. See the release notes for the changes.

One thing which caught was eyes was the introduction of the experimental profile mode.

It is true that programmers do misuse the STL. There should be some way to correct it. Now, need to get my hands dirty with the profile mode and see the usefulness.

DES with openssl v/s DESCryptoServiceProvider in .NET

Recently, I had to deal with some encryption, for which the documentation included some piece of code in VB, which used DESCryptoServiceProvider class for encryption. After spending almost a day trying to understand the implementation, I have come up with the equivalent implementation in C with openssl.

The stupidest thing, which I had to scratch my head for majority of the time spent on was the problem that, why is the VB code generating a 16-byte encrypted data for an input of length 8-bytes. I found the answer to this here.

Until now, I had been using the DES_* functions. After realizing that 8-byte padding is required, I had to use low-level EVP_* functions.

Some piece of code is given here:

EVP_CIPHER_CTX ctx;
EVP_CIPHER_CTX_init(&ctx);
EVP_EncryptInit_ex(&ctx, EVP_des_cbc(), NULL, key, iv);

EVP_CIPHER_CTX_set_padding(&ctx, 8);
//output_length and output_length1 need to be different.
EVP_EncryptUpdate(&ctx, output, &output_length, input, input_length);
EVP_EncryptFinal_ex(&ctx, output+output_length, &output_length1);
output_length += output_length1;

Phew...!!

be64toh - Another problem with gcc versions

Recently, I have been integrating another API, in which data transmission is in binary format, and as usual, the format is big-endian. Sounds familiar!!

Generally, in C, you have functions ntohl, ntohs, for converting long integer and short integer values from big-endian to the format of host machine. And obviously, they are more portable way of handling the conversion, rather that your test and shift method of conversion.

Now this time, I had to deal with some 64-bit data and was wondering if there were any functions, and I found the manual pages for endian. This was cool. A week later, I was ready to deploy for testing and got stuck with the problem of the function be64toh not being defined.

The problem was my development environment used g++ 4.4.1 and the test environment used g++ 4.3.2. Ohh god!!! What now? I tried searching for equivalent ones, and found some macros in /usr/include/byteswap.h.

So, now I modified my C++ code to look like this:

double readDouble(void * & data)
{
        uint64_t *ptr = (uint64_t *)data;
#if ( (__GNUC__ == 4) && (__GNUC_MINOR__ == 3) && \
             (__GNUC_PATCHLEVEL__ > 2) )
        uint64_t value = be64toh( *ptr );
#elif __BYTE_ORDER == __LITTLE_ENDIAN
        uint64_t value = bswap_64( *ptr );
#else
        uint64_t value = *ptr;
#endif
        ptr++;
        data = ptr;
        double *dptr = (double *)&value;
        return *dptr;
}

Code is now deployed for testing. :-)

ntohl and the left shift

Recently, I got into a small argument about an efficient code in converting big-endian data to little-endian. I was using `ntohl' library call and the argument against it was to use left shift and sum operation.

//Use ntohl
void *readUint32(void *ptr, uint32_t *value)
{
	uint32_t *uint_ptr = (uint32_t *)ptr;
	*value = (uint32_t)ntohl( *ptr );
	ptr += sizeof(uint32_t);
	return ptr;
}

//Use left shift
unsigned char *readUint32ByShift(unsigned char *p,unsigned int *n) 
{
        unsigned int v = 0;
        v <<= 8; v += *p++;
        v <<= 8; v += *p++;
        v <<= 8; v += *p++;
        v <<= 8; v += *p++;
        *n = v;
        return p;
}

This is with the implementation of a streaming market data with responses in network-byte (big-endian) order. Since it is time critical market data, the application should be faster in parsing and dispatching the data to end client.

The argument was that using `ntohl' was unnecessary, since the code is always going to run in x86 machine (little-endian) and will be faster than the library call implementation. Well, at that time, I didn't know how `ntohl' is implemented, and neither did I know if a left-shift will be faster than the library call. I did a benchmark and found that the library call implementation was twice as fast as the left-shift implementation.

Well, I got my answer.

Stupid FUTEX and glibc

I have a multi-threaded C++ application, used as a component end for one of the integration channels. Since last 2-3 weeks, I have been facing a strange issue of application getting hanged and not responding.

Debugging started with `strace' and I found that the application hangs in futex as:

futex(0x5ac9df, FUTEX_WAIT, ....

I thought, it had something to do with pthread_mutex that I was using, to share a queue across the application. I ensured that, pthread_mutex_lock and pthread_mutex_unlock are happening correctly, since problem solving always starts with the assumption that, the problem is in your code.

Well, I did that and also put more debug statements around usage of `mutex'. Unfortunately, that did not help, since the problem persisted.

I was on the verge of restructuring the entire application, when on googling `futex_wait hangs', I stuck upon a link, where there is a discussion about the same issue what I was facing. Some text from the link:

Unfortunately, ctime() is not defined on this list. So, glibc does not guarantee the sane behavior when one uses ctime() in signal handler. BTW, I'm surprised that sysklogd calls some functions in signal handler.

Unfortunately, my application was doing the same, i.e., using a function `localtime' (which calls __libc_lock_lock() in glibc), in a signal handler. I couldn't believe it. Though the purpose of the signal handler was to clean up resources and exit the application, I was logging some data. The logging function was calling `localtime'.

Pathetically, it has not yet been fixed, as it seems that this is a problem with glibc on 2.6 kernel, and not application programmers are at the disposal of glibc or kernel developers to fix this.

GnuTLS, OpenSSL, and libgcrypt

I had written a multi-threaded application in C++, which was using libcurl and GnuTLS for making https post requests to a webservice call. Now, when I was making individual requests, it was working fine and faster than an equivalent Ruby program. When I did a load test of 300 requests per milli second, it crashed with the following error:

ath.c:184: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)' 
failed.
Aborted!!

From the assertion, it seemed to be an issue with variables not being initialized. Digging more, I found people suggesting to use libgcrypt > 1.2, which was stable and has fixed this error. Well, I was not sure, that GnuTLS was using it and neither did I know that, a multi-threaded application will have to make some `init' calls before using the library calls.

Now, I found this link, which looked to me like the solution. But, it didn't look convincing. My idea was, if a library uses another library, it should do all these initialization tasks, rather than expecting the application to do it. :)

Well, I changed from GnuTLS to OpenSSL and, my load test seemed to work, without crashing the application.

Now, I am not sure, where will I end up, if I start exploring `GnuTLS versus OpenSSL`. That is not my current priority.

Making it work for different version

Few days ago, I found the solution for QuickFIX to make it work with g++ 4.3.X. I had to edit the source for QuickFIX and add two headers in src/C++/Utility.h.

#include <cstdlib>
#include <cstring>

This is fixed in the office laptop, which I am using at home. The next problem, I faced was making my FIX application to run with g++ 4.2 and 4.3 version. For this, I added the following lines:

#if ((__GNUC__ == 4) && (__GNUC_MINOR__ == 3))
#include <cstdlib>
#include <cstring>
#endif

That solved it!!

Now, whether I have a machine with quickfix installed, my application will work, irrespective of the version of g++. Hope g++ does not give more surprises.

FIX, third party software and adoption.

Financial Information eXchange or in short FIX, is an application layer protocol, adopted by a lot of organizations for financial information exchange. Refer, FIX Protocol for references.

I was introduced to it, in October, and a months work went into integrating FIX initiator application, to communicate with FIX gateways implemented by various Brokers. I struggled a bit, since there wasn't a straight forward documentation, to some developer level faqs. More so, because, I was writing a custom implementation for a broker (name cannot be disclosed), who is supposed to have the best FIX gateway among the US Brokers (ofcourse among those, who have adopted FIX).

During development, I was using g++-4.2 version, and I didn't have issues with compiling quickfix. Today, I was trying to deploy the application in my office laptop (for testing), with a fresh ubuntu installation, with g++-4.3. Compiling quickfix gave error like:

../Utility.h:179: error: 'std::strcmp' has not been declared
../Utility.h:181: error: 'std::strlen' has not been declared
../Utility.h:184: error: 'std::memcpy' has not been declared
../Utility.h:185: error: 'std::memset' has not been declared
../Utility.h:189: error: 'std::strerror' has not been declared

I searched further and found this link. I was surprised. I saw this document on porting issues to gcc 4.3.

In the office, I have always been skeptical about using third party software, and try to follow some simple check list before adopting to one of those.

• Use if the software is well documented, with reference to existing bugs, reliability and performance issues.
• Don't use the software, if it is not being maintained for more than last 6 months.
• Avoid using application level frameworks, which is heavy weight and try to abstract a lot of programming constructs.
• See business perspective, as in if a GPL licensed software is used, then what will happen to business, when you are distributing the software.
• Use the software, if time to market is minimal.
• Use it if you cannot think of writing the same piece of software in the near future (for e.g: the linux kernel or gcc compiler.)

cache programming

The type of applications that I am writing, use enormous amounts of RAM space, for storing processed data as cached data, so as to be used by various other applications. During this time is when I remembered about the cache (L1 and L2) used by the system processor. Though both are entirely different, it is the same as seen by a user. It is memory!!!

It is known that L1 and L2 cache are faster than the RAM, which is in turn faster than disk I/O. It is also know that L1, L2 caches are expensive than RAM.

This is when I came up with the problem of what If I wanted to make an implicit write to L1/L2 cache instead of the RAM, from a user space application.

I came up with quite a few interesting reads, and a patent for it. Check them out:

• Pentium 4 L2 cache optimization for cached writes
• Computer system cache performance...

Microsoft's cloud computing solution

A heavy-weight new entrant has appeared across the computing firmament: At its annual Professional Developers’ Conference (PDC2008), in Los Angeles, last month, Microsoft’s Chief Software Architect, Ray Ozzie, announced the company’s own offering in the growing list of products and services tapping into what is being called cloud computing.

Read more in this article, published in technology section of `The Hindu', paper.

Well, I am not new to cloud computing. I have been using AWS (Amazon Web Services) for more than 8 months, and I am simply amazed by it. You don't have to maintain physical servers. The hassles of upgrading hardware, managing internet/network connections are nullified. 2 servers for databases, 2 servers for backend applications and 2 server for web applications. But how much load can you handle with this setup. How will you address the issue of adding more servers, which require office space?

There are more issues in maintaining physical servers, data centers, which server administrators can understand. If all these are solved with a simple ssh access and pay as you use, it makes life easier.

People have already started using cloud computing, and with Microsoft's entry into this domain, the power of cloud computing will spread more rapidly now.