Tuesday, March 1, 2011

Debugging Tips - @CLK

We can use ‘Watch’ window to get time information. @CLK can serve as a timer in your watch window. In many cases, we just want a rough idea of the time between two points, and @CLK makes it easy to find out how long it took to execute between two breakpoints. Please note that this time includes the debugger overhead. The trick is to enter @CLK in watch window, running time between two breakpoints will be added up to the current clock value. You can reset the value by typing @CLK=0 in watch window.
The time is in microseconds, to get time in milliseconds, set the @CLK to @CLK/1000. Although it is not a perfect timer, @CLK is good enough for some general guesses.

Example:-
BEGIN_CODE
<- Add break point here (B1)
{
   
<<Code block>>
}
END_CODE
<- Add another break point here (B2)


Debug the code using F5. Once you reach B1, type @CLK in watch window which will display current clock value. Now type @CLK=0 in watch window to reset the clock. Now press F5 to continue, once the control reaches B2, watch window will show the time taken for executing code block between B1 and B2.

Note: This will not include the break time @B1.

Posted By : Junaij M

Access Computer Information with the System Information Tool

Title - Access Computer Information with the System Information Tool

Details - Windows XP has a built-in tool that offers a wealth of information about your computer. System Information gives users rapid access to hardware resource and software environment information, component and application data, system history, useful tools such as Net and Direct X Diagnostics and much more.


System Information can be a very useful tool for troubleshooting computer problems. For example, digging into items listed in the "Software Environment" can give you information about which programs have recently experienced serious errors, driver details, network connections, running tasks and more. The System History view records changes to hardware resources and the software environment and this can help you track down problems that may have occurred due to driver upgrades or hardware changes.


An integrated search feature allows you to more easily find what you are looking for.


To launch the System Information tool:

   1. Click "Start" and then "Run".
   2. In the Run field, enter "msinfo32.exe" without the quotes.
   3. Click "OK" and the tool should launch.


Alternatively, you can click "Start /All Programs/Accessories/System Tools/System Information" to open the tool directly from the Start Menu.

Reference :-
http://www.xp-tips.com/system-information-tool.html



Posted By : Preethymol K. S

Why You Shouldn't Store auto_ptr Objects in STL Containers

Title - Why You Shouldn't Store auto_ptr Objects in STL Containers

Details - copying or assigning one auto_ptr to another makes changes to the original in addition to the expected changes in the copy. To be more specific, the original object transfers ownership of the pointer to the target, thus making the pointer in the original null. Imagine what would happen if you did something like this:


std::vector <auto_ptr <Foo> > vf;/*a vector of auto_ptr's*/
 
// ..fill vf
int g()
{
  std::auto_ptr <Foo> temp=vf[0]; /*vf[0] becomes null*/
}

When temp is initialized, the pointer of vf[0] becomes null. Any attempt to use that element will cause a runtime crash. This situation is likely to occur whenever you copy an element from the container. Remember that even if your code doesn't perform any explicit copy or assignment operations, many algorithms (std::swap(), std::random_shuffle() etc.) create a temporary copy of one or more container elements. Furthermore, certain member functions of the container create a temporary copy of one or more elements, thereby nullifying them. Any subsequent attempt to the container elements is therefore undefined.

Reference –
http://www.devx.com/cplus/Article/16328/0/page/6

 Posted By : Preethymol K. S

Integrated Performance Primitives (IPP

Tip - About Integrated Performance Primitives (IPP)

Details -  Multicore Power for Multimedia and Data Processing

Intel® Integrated Performance Primitives (Intel® IPP) is an extensive library of multicore-ready, highly optimized software functions for multimedia, data processing, and communications applications. Intel IPP offers thousands of optimized functions covering frequently used fundamental algorithms.

 

Performance
Intel IPP functions are designed to deliver performance beyond what optimized compilers alone can deliver, by matching the function algorithms to low-level optimizations based on the processor's available features such as Streaming SIMD Extensions (SSE) and other optimized instruction sets.
Support for multicore processors
Intel® IPP functions are fully thread-safe, and many are internally threaded to help you get the most out of today’s multicore processors.

Operating systems

Use the same API for application development on multiple operating systems: Windows*, Linux* and MAC OS*.

Programming languages

Intel® IPP natively supports C and C++ development; cross-language usage examples provided for C#/.NET and Java*.

Processor support

Intel® IPP is validated for use with multiple generations of Intel® and compatible processors including but not limited to: Intel® Atom™ processor, Intel® Core™2 processor, Intel® Core™ processor, Intel® Pentium® D processor, Intel®
Pentium® M processor, Intel® Xeon™ processor, Intel ® Pentium® 4 processor, Intel® Celeron® processor.

Source code usage samples

Jumpstart your application development with source code samples incorporating Intel® IPP, including video/audio/speech codec’s, image processing, data compression, and other high-level algorithm implementations.

Support for future instruction sets and additional CPU cores

Intel® IPP is optimized for current multicore and future manycore processors. As new instruction sets become supported in Intel CPUs, just relink with the latest version of Intel IPP to achieve the greater application performance provided by the new instruction sets.

Royalty-free redistribution

Redistribute unlimited copies of the runtime libraries with your application.

Reference:

Posted By : Binu M D 
 

Wednesday, February 23, 2011

Debugging a blue screen

Title - Debugging a blue screen

Details - Have you ever wondered how to obtain extra information from the infamous Blue Screen of Death (BSOD) that will sometimes show up and give you a cryptic, Stop: 0×00000000 error message, before flashing off the screen? The error message is trying to point you to a fatal operating system error that could be caused by a number of problems. When the system encounters a hardware problem, data inconsistency, or similar error, it may display a blue screen containing information that can be used to determine the cause of the error. This information includes the STOP code and whether a crash dump file was created. It may also include a list of loaded drivers and a stack trace.
Microsoft’s WinDBG will help you to debug and diagnose the problem and then lead you to the root cause so you can fix it.
Steps For Analyze
  1. Create and capture the memory dump associated with the BSOD you are trying to troubleshoot.
  2. Install and configure WinDBG and the Symbols path to the correct Symbols folder.
  3. Use WinDBG to Debug and analyze the screen dump, and then get to the root cause of the problem.
Minidump
A minidump is a smaller version of a complete, or kernel memory dump.  Usually Microsoft will want a kernel memory dump.  But the debugger will analyze a mini-dump and quite possibly give information needed to resolve.  If it's all you have, then debug it, rather than waiting for the machine to crash again.  Open the file in the debugger (see below) just as opening memory.dmp.
Steps to create memory dump
Keep in mind that if you are not experiencing a blue screen fatal system error, there will be no memory dump to capture.
1. Press the WinKey + Pause.
2. Click Advanced, and under Start Up and Recovery.
3. Uncheck Automatically Restart.
4. Click on the dropdown arrow under Write Debugging Information.
5. Select Small Memory Dump (64 KB) and make sure the output is %SystemRoot%\Minidump.
6. Restart the PC normally, as this will allow the System to error and Blue Screen and then create the Minidump.
The location of the Minidump files can be found here:
C:\WINDOWS\Minidump\Mini000000-01.dmp
To download and install the Windows debugging tools for your version of Windows, visit the Microsoft Debugging Tools Web site.
Follow the prompts, and when you install, take note of your Symbols location, if you accept the default settings this Microsoft Support Knowledge Base article will explain how to read the small memory dump files that Windows creates for debugging purposes.

Dump Analyze using WinDBG

 Open WinDBG and select File and select Open Crash Dump and then navigate to the minidump file created earlier, highlight it, and select Open.
Click on:
! analyze –v
As shown in Figure C under Bugcheck Analysis.

Figure C

! analyze -v

Conclusion

The problem creating the BSOD was caused by the installed driver software for a USB modem. The answer to the problem was achieved by using the WinDBG tool to Debug and analyze the memory dump file.

Reference:

Posted By : Binu M D 

More on OpenMP

Title -More on OpenMP

Details - OpenMP is an implementation of multithreading, a method of parallelization whereby the master "thread" (a series of instructions executed consecutively) "forks" a specified number of slave "threads" and a task is divided among them. The threads then run concurrently, with the runtime environment allocating threads to different processors.
The section of code that is meant to run in parallel is marked accordingly, with a preprocessor directive that will cause the threads to form before the section is executed. Each thread has an "id" attached to it which can be obtained using a function (called omp_get_thread_num()). The thread id is an integer, and the master thread has an id of "0". After the execution of the parallelized code, the threads "join" back into the master thread, which continues onward to the end of the program.
By default, each thread executes the parallelized section of code independently. "Work-sharing constructs" can be used to divide a task among the threads so that each thread executes its allocated part of the code. Both task parallelism and data parallelism can be achieved using OpenMP in this way.
The runtime environment allocates threads to processors depending on usage, machine load and other factors. The number of threads can be assigned by the runtime environment based on environment variables or in code using functions. The OpenMP functions are included in a header file labelled "omp.h" in C/C++.


Implementations

OpenMP has been implemented in many commercial compilers. For instance, Visual C++ 2005, 2008 and 2010 support it (in their Professional, Team System, Premium and Ultimate editions), as well as Intel Parallel Studio for various processors.

Pros and cons

Pros
  • Data layout and decomposition is handled automatically by directives.
  • Incremental parallelism: can work on one portion of the program at one time, no dramatic change to code is needed.
  • Unified code for both serial and parallel applications: OpenMP constructs are treated as comments when sequential compilers are used.
  • Original (serial) code statements need not, in general, be modified when parallelized with OpenMP. This reduces the chance of inadvertently introducing bugs.
  • Both coarse-grained and fine-grained parallelism are possible
Cons
  • Risk of introducing difficult to debug synchronization bugs and race conditions.
  • Currently only runs efficiently in shared-memory multiprocessor platforms .
  • Requires a compiler that supports OpenMP.
  • Scalability is limited by memory architecture.
  • no support for compare-and-swap
  • Reliable error handling is missing.
  • Lacks fine-grained mechanisms to control thread-processor mapping.
  • Can't be used on GPU
  • High chance of accidentally writing false sharing code

Performance expectations

One might expect to get an N times speedup when running a program parallelized using OpenMP on a N processor platform. However, this is seldom the case due to the following reasons:
  • N processors in a SMP may have N times the computation power, but the memory bandwidth usually does not scale up N times. Quite often, the original memory path is shared by multiple processors and performance degradation may be observed when they compete for the shared memory bandwidth.
  • Many other common problems affecting the final speedup in parallel computing also apply to OpenMP, like load balancing and synchronization overhead.


Posted By : Binu M D 

Double buffering in computer graphics

Title :- Double buffering in computer graphics

Details :-  In computer graphics, double buffering is a technique for drawing graphics that shows no (or less) flicker, tearing, and other artifacts.

It is difficult for a program to draw a display so that pixels do not change more than once. For instance to update a page of text it is much easier to clear the entire page and then draw the letters than to somehow erase all the pixels that are not in both the old and new letters. However, this intermediate image is seen by the user as flickering. In addition computer monitors constantly redraw the visible video page (at around 60 times a second), so even a perfect update may be visible momentarily as a horizontal divider between the "new" image and the un-redrawn "old" image, known as tearing.

A software implementation of double buffering has all drawing operations store their results in some region of system RAM; any such region is often called a "back buffer". When all drawing operations are considered complete, the whole region (or only the changed portion) is copied into the video RAM (the "front buffer"); this copying is usually synchronized with the monitor's raster beam in order to avoid tearing. Double buffering necessarily requires more video memory and CPU time than single buffering because of the video memory allocated for the back buffer, the time for the copy operation, and the time waiting for synchronization.

Compositing window managers often combine the "copying" operation with "compositing" used to position windows, transform them with scale or warping effects, and make portions transparent. Thus the "front buffer" may contain only the composite image seen on the screen, while there is a different "back buffer" for every window containing the non-composited image of the entire window contents.
Page Flipping

In this method (sometimes called ping-pong buffering), instead of copying the data, both buffers are capable of being displayed (both are in VRAM). At any one time, one buffer is actively being displayed by the monitor, while the other, background buffer is being drawn. When drawing is complete, the roles of the two are switched. The page-flip is typically accomplished by modifying the value of a pointer to the beginning of the display data in the video memory.

The page-flip is much faster than copying the data and can guarantee that tearing will not be seen as long as the pages are switched over during the monitor's vertical blank period when no video data is being drawn. The currently active and visible buffer is called the front buffer, while the background page is called the 'back buffer'.



Posted By : Binu MD