29 Ekim 2008 Çarşamba

Recursive fibonacci Case Study

In that post i'm going show u a test that i made about recursive calls in Python compared to other languages. The tests used are Python,Python C extension and Java. I always heard that using recursive calls in Python is not very wise, that time i decided to discover it myself. Well i run the 3 programs to find finacci 40. number and got their times with time command in F9. Tests do not claim anything so do not bother me with garbage :) Here they are :

[makkalot@localhost pyalgorithm]$ time python py_fibo.py 40
The result is : 102334155

real 6m32.110s
user 6m22.153s
sys 0m0.519s

Python_Ex :
[makkalot@localhost fibo]$ time python ex_fibo.py rec 40
The recursive result is : 102334155

real 0m3.039s
user 0m2.902s
sys 0m0.017s

[makkalot@localhost bin]$ time java sorts.FiboMan rec 40
The recursive result is 102334155

real 0m4.053s
user 0m2.755s
sys 0m0.095s

Conclusion : The results suprised me a little bit. I knew that Python as a recursive language is slow but the time above is a disaster. Therefore i know now if i need sth recursive in Python i will write it as a C extension. The java also suprised me because its time was very close to C extension. Those Java guys are getting better, maybe JavaFX may make to become a Java programmer :)

Btw, here are the codes :
Python : Link
C extension : Link
Java : Link

A new Django Site Added to public

In last 2 weeks i've been working as freelancer, searching for people around the world who need Django/Python help for their projects. It is kind of exciting because i meet new people and do different kind of work everytime. Well one of these was injazzat.com a static firm site which was converted to Django site. The guy who was responsible for that site hired me to fix some of bugzz in site. It seemed as an easy stuff there was a few typos some template errors. However when i went deeper into code saw that hardcoded parts that made that job a nightmare :) I spent all my week to fix that mess and now most of the parts are real dynamic and the site follows the DRY :) At the end of work the guy told me that i was the 4th person who tried to fix that site and succeed finally. All previous developers escaped or dissappeared ... The temporary link of site is here ,i dont know if it will be there tomorrow but as reference just put it here. I hope got more exciting projects in the future ...

To conclude , do not write hardcoded programs because someday they will be seen by other people believe me :)

Note : and also thanks to adk for his help with those designer and css stuff

Make Python Smoke

In that post i'm going to talk i little bit (not too much ) about some old computer problems. ı have always been excited bout that kind of problems some of most famous ones are :

* Producers-consumers problem
* Dining philosophers problem
* Sleeping barber problem
* Readers-writers problem

All of them has a main purpose to make computer to solve the problem by using threads/processes and semaphores/locks. When think about those problems always my head is going to explode (hey i'm not so clever) and that is the fun part :) I had OS lessons in university but never had chance to write the implementation of these problems (what a practical school). Therefore i decided to write some of these problems in Python so i can explode my head and have fun with Python. One that i have written is Cigarette smokers problem [1] and put its code on my public git repo so other folks can grab it and play with it. The code is here : Link

To run the code just python cigarrette.py and watch how people smoke and die :) If you discover some deadlock or any other fatal mistake please drop a comment to light me .Have fun!

Resources :
[1]Wikipedia : http://en.wikipedia.org/wiki/Cigarette_smokers_problem
[2]My public git repo : http://github.com/makkalot/pyalgorithm/

16 Ekim 2008 Perşembe

Hash That Diectory - Case Study

Hash That Directory - Use Case

In my spare time i try to finish my pysigner software. My aim for that project was to make a tool similar to keytool (Java). Therefore someone who needs
to add that X.509 stuff in its application can use my pysigner. One of the part that i'm writting now is to collect the sha1sums of a directory so i can sign verify the contents of that directory.
Computing the hashes is really easy you get some data in buffer and call the sha.update() method and then you have the hash. Firstly i have written that
part in normal way. By normal i mean without using threads. After that i thought it would be better to use threads for that purpose because most of the time we do IO operations. That way the python thread manager will switch when i read into buffer and will do the computation in another one ,cool isnt it ? Actually i was expecting a very big difference in times between normal and threaded implementation. Ok talk is cheap give the code and times :

Normal implementation :
[makkalot@acerfedora pysign]$ time python top_level.py
Straight Tester ...

real 9m52.081s
user 2m23.076s
sys 0m51.895s

4 THreaded implemenatation:
[makkalot@acerfedora pysign]$ time python top_level.py
4 Threadded Tester ...

real 10m7.411s
user 1m50.216s
sys 0m42.488s

8 Threaded implementation:
[makkalot@acerfedora pysign]$ time python top_level.py
8 Threadded Tester ...

real 10m23.042s
user 2m42.285s
sys 0m59.676s

The results are really strange are the Python threads a big illusion ? Sometimes i think they are like mastubation nothing real at all :)
BTW, if someone finds a bug and thinks it can be improved plz comment ...

Here is the normal implementation :
Link :
Here is the theraded part :
Link :