Monday, November 26, 2007

Server-Side Include in Apache

(Nov 26, 2007)

I tried using server-side include (SSI) feature in Apache 2.2.6. I followed all steps in its documents. These are:
1. use Options +Include in
2. use AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
within mime_module (just uncomment these two lines in httpd.conf)
3. use an include element, such as

However, it turned out that my stuff did not work. I spent about two hours to figure this out. Finally, I knew that .shtml did not mean a file to be included., but .shtml meant a file that included other files. Namely, I just renamed a 'master' file, menu.html, to menu.shtml, and every thing worked fine.

Moreover, a file to be included can be .html, no need to make it .shtml.

Note: although it is possible that we can allow .html to be a master file in the same way by adding AddOutputFilter INCLUDES .html, I will not do this since 3rd party server may not allow us to do this (I think it might slow down the web server).

Friday, November 23, 2007

หัดใช้ SSE

(Nov 23, 2007) (Thanksgiving Night)

Today, I tried using vector instructions (SSE2 to be specific) in Visual C++ 2003. There are something worth noting:
1. we might always want to use _mm_malloc( data_size, 16 ) in place of new operator to make sure that our dynamically array will be aligned at 16 bytes (this is a restriction for many operations in SSE2; otherwise we will get memory exception). More details can be found at http://www.x86.org/articles/sse_pt3/simd3.htm and http://www.tacc.utexas.edu/resources/user_guides/intel/c_ug/linux117.htm

Remember that, to free the allocated memory, use _mm_free.

2. For those using Visual C++, they have alternatives when they want to aligned data. For example,
__declspec(align(16)) float m_fArray[ARRAY_SIZE];

and
m_fArray = (float*) _aligned_malloc(ARRAY_SIZE * sizeof(float), 16);

Please see more info at http://www.codeproject.com/cpp/sseintro.asp

3. As can be seen from 2, it is desirable to align our floating-point array as well since this will allow us to cast-and-use the floating-point array.

4. There are interesting classes which are suitable for vector instructions: vector3D and 4x4 Matrix. Please see http://www.x86.org/articles/sse_pt3/simd3.htm (near the page bottom).

More may be available at http://www.codeproject.com/useritems/SSE_optimized_2D_vector.asp (see the source code package).

5. Examples in using add, mul, and sqrt via SSE: http://www.codeproject.com/cpp/sseintro.asp

6. memcpy and _mm_loadu_ps will play an important role to increase speed for convolution since SSE needs to align data at 16 bits, but we want to move convolution window little by little (4 bytes). However, if we interleavedly process data, we need to perform memory move / copy only four times. This should be good for performance improvement.

There is a website about fast factor 2 resampling using SSE at http://mail.gnome.org/archives/beast/2006-March/msg00001.html. I don't know if it does show something related to my convolution problem, but I will one day take a look at it seriously.



7. Very simple example of SSE in GCC: http://www.tuleriit.ee/progs/rexample.php

Thursday, November 08, 2007

Deprecated String-Conversion Macro

(Nov 8, 2007)

Today, I spent a lot of time trying to nicely rid of some warning messages:
warning C4995: 'gets': name was marked as #pragma deprecated
warning C4995: 'sprintf': name was marked as #pragma deprecated
warning C4995: 'vsprintf': name was marked as #pragma deprecated
warning C4995: 'strcat': name was marked as #pragma deprecated
warning C4995: 'strcpy': name was marked as #pragma deprecated
warning C4995: 'swprintf': name was marked as #pragma deprecated
warning C4995: 'vswprintf': name was marked as #pragma deprecated
warning C4995: 'wcscat': name was marked as #pragma deprecated
warning C4995: 'wcscpy': name was marked as #pragma deprecated

These seems to happen when I try to employ some ATL stuff along with its string conversion features in Visual C++ 2005. Although, I used ATL 7.0 which should not be deprecated, these warning messages still haunted my compile message.

For some unknown reasons, I found that including iostream would automatically be removed. I don't know why, but it does do a trick.

Update: these warning occurs because those deprecated functions are called internally in conversion macros. If we include iostream, some function calls in these macros may be different. Also note that if we explicitly call those deprecated functions, including iostream will do nothing, and we need to explicitly use secured functions, such as sprintf_s instead.