One of the benchmarks at the computer languages game requires that a program parse a 'stdin' redirected input of these FASTA formated sequences and print the content of the sequence in reverse order. Each character in the sequence should also be complemented according to this translation table:

code  meaning   complement

A    A                   T
C    C                   G
G    G                   C
T/U  T                   A
M    A or C              K
R    A or G              Y
W    A or T              W
S    C or G              S
Y    C or T              R
K    G or T              M
V    A or C or G         B
H    A or C or T         D
D    A or G or T         H
B    C or G or T         V
N    G or A or T or C    N

Headers

Each sequence contains a header with an id and description. These lines are printed 'as is' .

Challenges

• String reversal
• Translation table substitution
• Input handling and memory allocation

String Reversal

Sequences are reversed using a bitwise XOR and without using a temporary character or string buffers.

Operations are performed in a loop where forward is the first index and end is the last index in the sequence.

buffer[forward]^=buffer[end];
buffer[end]^=buffer[forward];
buffer[forward]^=buffer[end];

Translation table substitution

A small character array of complement values is created and accessed with the integer value of the source character matching to arrays index. For example:

buffer[end]=FtoCOMP[buffer[end]];

Buffer at index end will receive a character at index 'buffer[end]' from translation table array FtoCOMP. Index 'buffer[end]' translated to an integer , will point to a desired complement . This speeds up the process of substitution and allows for very fast array index notation.

Input handling

The requirement to handle input one line at a time corresponds quite well to the translation procedure. In pseudo-code,

• process one line at a time
• for each sequence , print header line, reverse the sequence, translate it into its complement and print it out

Only one buffer is used as a destination for reading input. Beginning pointer where each line is placed is dictated by moving a pointer through a character array. Once a line is read in, we check if it is the last line in a sequence by peeking into the input stream. If it is , it is processed according to above instructions and beginning pointer where the next line is placed is reset to 0.

These functions are called for each line N in the input stream:

fgets_unlocked, fgetc_unlocked.

These functions are called for each line that's not a header line:

ungetc, strlen.

Other functions are called only at the end of a sequence and do not approach N runtime. This version written in C language has been compiled and tested using kernel 2.6.24 with GCC 4.2.3 .

Compile command:

gcc -Wall -O3 -fomit-frame-pointer revc.c -o revc.gcc_run

Source code is located here: http://zenebo.com/revc.c.tar.gz

My solution has been accepted and placed in the interesting alternative category. A bitter-sweet victory considering my program as tested by their standards is the fastest C language entry . It is still a small honor to be recognized and to know that my entry shaved off almost 30% off the next fastest C program.

Let's see how the FASTA benchmark program stacks up in the next few days.

Cheers.

see it here: http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all

The computer language benchmarks game at http://shootout.alioth.debian.org/gp4/index.php matches up a fundamental processing task or algorithm in a variety of programming languages. One benchmark called 'sumfile' has the following requirements:

• read integers from stdin, one line at a time
• print the sum of those integers

It is based on this icon program:

procedure main(argv)

 sum:=0

 while(sum+:=read())

 write (sum)

end

The C language entry topped at 6th and 7th place. Surprising as it was, a Java 6 version came in second with more than a second shaved off the total CPU running time.

The task for all of these is to read a flat file containing one integer per line, add the integer to the total and print out the sum at the end. Three versions of test files containing 1,000, 11,000 and 21,000 lines are used. While there could be more interesting ways to tackle this task, it's trivial and simple demands warranted a quick look.

The fastest C program used these function calls per each line in the file:

fgets_unlocked() , atoi() and a += operator to sum up the total. It seems that either one of these functions could be improved on, but since line-by-line reading is a strict requirement thus leaving the atoi function open to critique.

This following function will return an integer given a string. It handles positive and negative number strings.

int matoi(char *c) {

int res = 0,n=1;

if(*c=='-'){n=-1;*c++;}

while (*c >= '0' && *c <= '9')

res = res * 10 + *c++ - '0';

return res*n;

}

When compared to the standard atoi() function and parsing 500,000 lines of integers, this version on a 2.4 GHz Core2Duo performed 60% better . It's simplicity is also it's weakness as the matoi() function is designed to handle proper input. Perfect for a situation where input is controlled.

Original benchmark entry was modified with timing capture and the addition of matoi() function. Header contains any previous entry owners and information.

Archive with source code : http://zenebo.com/sum1.c.tar.gz

Cheers

There are many well written , fast web servers around with full features for CGI , FastCGI , proxying and dynamic language support such as Ruby, PHP and Python. So what is Lighttz ? It's a small HTTP server written in C , benchmarked against the big guns. It is by no means a replacement for the big four, and is mainly a testing showcase. For the sake of brevity, the comparison of the first benchmarks will compare the following web servers:

• Apache/2.2.8-mpm-prefork
• lighttpd/1.4.19
• nginx/0.5.33
• userver-0.6.0 - compiled and run with epoll support
  
• lighttz/0.1 - libev epoll event model
  

Short summary and the configuration as tested is below. Please note that other event models such as select and poll are available under each server , but these were picked for the performance or wide use ( in case of Apache ) .

Apache - http://httpd.apache.org/

The usual pre-forking server most, widely used to power many websites.

Lighttpd - http://www.lighttpd.net/

Also a very popular server. Instead of a forking model, it utilizes a fast a very well performing epoll mechanism.

Nginx - http://sysoev.ru/en/

A little younger but equally fast server , which also utilizes epoll event model.

Userver - http://userver.uwaterloo.ca/index.php

A small, microwebserver that's mostly used for tests and benchmarks. Project is maintained at University of Waterloo.

Lighttz -

A short C program that simulates an HTTP server and handles the requests using Libev and epoll.

Test platform

Ubuntu 8.04 , Kernel 2.6.24-16 SMP , 2GB RAM, Core2Duo 2.4GHz

Benchmarking Client Program

ApacheBench . Command used:

ab -c1000 -n1000000 <host:port> . The test document index.html is a 357 byte static file. Lighttz did not use the static file, it sent out the exact same contents as index.html contained in a char array.

The above simulated 1000 concurrent clients making 1000000 requests .

Results

Each result is an average of three runs with one pre-warming run to let each server utilize the cache.

Requests per second. Listed in order of fastest to slowest.

1. Lighttz - 14,719 ( Cpu usage: 40-50% , Memory: 188 KB , 1 process )
2. Lighttpd - 14,701 ( Cpu usage: 65-85%, Memory: 6.6 MB , 1 process )
3. Nginx - 14,378 (Cpu usage: 65-80%, Memory: 2.1 MB , 2 processes )
4. Userver - 13,221 ( Cpu usage: 75-90%, Memory: 1.2 MB, 1 process )
5. Apache - 9,512 ( Cpu Usage: 60-80%, Memory: 3.5 MB x 147 processes , 514 MB total )

Hardware used, other running servers and operating systems will reflect different results. The tests were not run to define maximum performance for all solutions. Each application will apply a different level of stress on the server.

Source code for Lighttz : http://zenebo.com/lighttz.c.tar.gz

Lua version: http://zenebo.com/lighttz_lua.tar.gz

Libev : http://software.schmorp.de/pkg/libev.html

Index.html file was taken from SuperJared.com article located here: http://superjared.com/entry/benching-lighttpd-vs-nginx-static-files/

Who doesn't like Pong ? A breakout hit of epic proportions, Pong has traversed a long and arduous path into our hearts.

The program is written in C++.Net and utilizes basic Windows GDI features to simulate a game of Pong.

Login

Once the program runs, it requires the user to login. Login process creates a flat binary file in the same directory as the executable.

The archive below has one pre-registered user:

Login:demo

Password:demo1!

Implementation

Core of the program is based around learning graphical user interface programming using C++.Net , expanding concepts of threading and communicating a managed application with an unmanaged dynamic link library file. The program loads a previously created unmanaged Win32 .dll file from the ReleaseDll directory.

The program does not attempt to adhere to actual rules of Pong nor does it try to play with intelligence. I like to win , what can I say

Zip archive is located here: http://zenebo.com/gui546a2.zip

Introduction

One of the interesting features of MSN Messenger is that you can see if a person is online and be able to look up their personal status . Some fields can be used to indicate a status such as : at work or at home

The task in this assignment is to write a server and a client that allows user to register with the server and see which other registered users are on .

Specification

A user will run the heythere client and connect to a heythere-server . Every N seconds, the server will send to the client a list of users that are currently registered and their status.

Client

The client first sends the user name to the server. The second message the client sends to the server is the location of the client . Other messages can be sent to the server. User can change their user name, the location and it may add a message tag .

Every time interval in seconds, the server will send a complete list of the currently logged on users. The client will print these out to stdout .

Each message has a strict format described as following:

First 3 characters describe the type of message the client is sending followed by a space and then the content of the message .

Location: usr

Hostname: loc

Message: tag

Server

Server is written to support up to 30 clients at a time. It uses select to multiplex between different clients. If the command-line arguments -t <time interval> are not given, the default value for the number of seconds between printing to the clients is 10 seconds . Information will be written on line per client in the following format:

<user name> <location> <message tag>

To handle client data, the server collects the information from all connected clients.

Zip archive is located here: http://zenebo.com/csc209a4.zip

Build

In this assignment a student is required to write a program in Bourne shell that performs some of the same operations that make does . A simpler file format for a build file is specified , which does not follow all rules of the make program .

Build file format

There are 4 types of valid lines in a build file:

1. A blank line. I.e., a line containing nothing but whitespace.
2. A line whose first character is # which indicates that the remainder of the line is a comment.
3. A line whose first character is an @ followed by a space, and then followed by one or more words separated by a single space. This type of line marks the beginning of a build rule. The @ is ignored. The first word in the sequence is the target of the rule, and the remaining words, if any, are the prerequisites for the rule.
4. Other lines are considered action lines which should be executable statements.

In example:
#Comment line
@target prerequisite1 prerequisite2
action
action with arguments


Functionality and Implementation

build program will take one or two arguments. The first argument is the target that you want to build. The second argument is the name of the build file to the program will read. If the second argument is not present, the program will try to read a file in the current working directory called buildfile.

Steps:

1. Read the build file looking for the appropriate rule. If found:
2. Update prerequisites. (as with make, each prerequisite corresponds to a target in the buildfile, so we might need to execute another rule to ensure that a prerequisite is up to date.)
3. If the target is a file and has been modified more recently than all of its prerequisites, then the actions are not executed.
4. If the target is not a file, or any of the prerequisites are newer than the target, then the rule's actions are executed.

Exceptions:

• If a rule has no prerequisites, then the rule will always be executed when it is encountered. Note that this differs from make where a rule with no prerequisites is only executed if it is called explicitly.
• You don't need to handle recursive targets and prerequisites.

The build process will likely want to call the build program from within the build program. (Recursion comes in many forms.) The best way to do this is to make sure that build is in a directory in the PATH variable.

Testing

Another obvious use for shell scripts is to automate testing programs. We will also write a shell script called testbuild that will run several tests of the build program.

The testbuild program will run at least 3 different test cases that test different parts of the program. We will also need to include one or more build files and possibly some other files. The touch (see "man touch") command will come in quite handy when we want to change a file's modification time automatically.

Zip archive can be obtained here: http://zenebo.com/csc209a1.zip

Peg solitaire is a game where a set amount of pegs are filled in on a board with a set amount of pegs slots. To solve the Solitaire, a player consecutively jumps a peg over another peg , which in turn is emptied out. This process is repeated until there is only one peg on the board.

A C++ program that takes a file name as input . It expects the first line to be in this format:
,
where height and width are valid integers. Using these numbers, it processes the rest of the file using this format:
Character 'O' is an empty peg.
Character 'X' is a taken peg.

Once the board is parsed , if the board has a solution thus has only one peg left , it will print out the consecutive steps to solve it or it will print "No solution" if a solution can't be found .

Instructions

Using command prompt: <executable> <test board>

Boards can be downloaded below the source code download link, or a new board can be created as long as it follows above format.

Zip archive is located here: http://zenebo.com/solitaire.zip

Test boards can be downloaded here : http://zenebo.com/solitaire_test_boards.zip

As the article name suggests, there is a variety of ways to enjoy the sheer goodness that these games have to offer. A frequent course of action is to set-up an online community. An organized , group centric approach offers many rewards to the players as well as to game publishers alike . It cultivates fan created content, fosters online discussions, allows for inter-clan or casual leagues to form and most of all keeps the players connected and organized in an otherwise distant field of online gaming.

The Orange Box exploded into a present form of an online juggernaut . Fueled by constant improvements to the underlying Steam platform, players gain ability to form groups , connect with their friends and merge into distinct groups. Outside of Steam platform, a separate world exists and caters to extend the experience. The dedicated online server communities are the main attraction to more serious gamers . The following paragraphs explain the experience and steps taken to build one of them : The Last Gunslingers , tagged by [TLGS] .

Server Types

An administrator can choose a pre-installed or a self managed solution . The self managed solution is more flexible, usually more expensive and often more hardware specific to its use. Important things to look for are:

• Bandwidth
• RAM
• CPU
• Operating System
• Network Throughput

There could be other factors that can affect the overall performance of the servers , but these are a good start. Let's look at a general overview of the above.

Bandwidth

A game server needs to be able send and receive packets with the least amount of latency. A data center provided 10 Mbit connection can handle one or multiple server instances running on the same physical machine. A Team Fortress 2 server handling 32 connected players will require similar numbers to the ones below . Server variables that dictate how the server operates may change these dramatically , but overall it is about hitting that performance to price sweet spot .

Rate of data flowing to clients from the server:

2.7 - 3.0 Mbps

This translates to roughly 2.0 - 2.5 Gigabytes of data being sent by the server per hour .

Rate of data flowing to the server from clients:

0.6 - 0.9 Mbps

This translates to roughly 250 Megabytes of data received by the server per hour . These are minimum requirements for a quality sustained connection. A safe practice is to not over saturate the line and leave at least 20% of connection cap free. This will help to eliminate network choke , otherwise known as a network lag .

Summing up possible requirements can be attained by calculating per player / slot network liability .

One player will require on average : 100 Kbps download and 18 Kbps upload .

A common limiting factor is monthly bandwidth allowance . One full server operating 24 hours a day will push about 900 Gigabytes of traffic per month. Most common server carriers will be able to sustain these transfer speeds as well as data transfers.

Above network usage is based on these server variables:

sv_minrate 13000
sv_maxrate 25000
sv_minupdaterate 10
sv_maxupdaterate 33
sv_mincmdrate 10
sv_maxcmdrate 33

Next we'll look at the other requirements in the equation such as the CPU and RAM , etc.

Main website located at http://orange.half-life2.com contains more information on the Orange Box compilation.

Wikipedia page is located at http://en.wikipedia.org/wiki/The_Orange_Box.

Orange Stats will insert extracted data into a database for later use by a web front-end or a Team Fortress 2 in-game plugin. The table schema is a bare bones implementation that supports CP map style gameplay. Design requirements focused on simplicity and light weight code implementation. Following game events are captured and categorized :

• Connect
• Disconnect
• Map load
• Join Team
• Point Capture
• Point Capture Block
• Pick Character Class
• Player Death
• Player Assist
• Revenge
• Built Object
• Destroy Object
• Domination
• Steam user events ( user ticket validation )

Character class specific data extraction works for events such as:

• Sapper events, Uber charge events, Engineer object events

A web front-end will be uploaded along with the database schema as soon as possible. Orange Stats working demo can be viewed here . Web front-end features a slight AJAX touch through PrototypeJS .

Back end runs a light PHP script.

Python script is located here .

Current release of Upkextract can parse a UT3 resource file and find any sounds contained inside it. Unreal Tournament 3 uses Ogg Vorbis files for sound effects and encodes them using Xiph.org's libVorbis aoTuvb5 library.

Sound file metrics such as gain, channels and others are not extracted in this release.

Archive contains the executable and a sample resource file from UT3.

http://zenebo.com/upkvorbisextract.zip