Alo Sarv
lead developer

Donate via

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary

Saturday, April 23, 2005

The daily post

You are not going to abandon us now, will you? I mean wtf - who's going to keep us company.

I don't know - blog about whatever comes to your mind. Is 64bit better than 32bit for the donkey network? Should sha1 be replaced by sha256? Should the code be refactored to throw exceptions instead of ints? How many unique downloads you got today for the core? What do you think of (implementing) this or that other P2P? Need I go furhther :)

Hehe. Abandon? Naah, hydranode has way too much potential, way too interesting future to abandon this blog. You are right ofcourse, there are always things to blog about. But sometimes there are times when few days break from blog can go a long way towards writing more interesting blog posts, I tend to believe in quality rather than quantity.

An interesting thing I found out few days ago ... I had heard ppl talking that MSVC has nice optimizer, but never really had chance to experience it first-hand myself, until few days ago ... comes out, hydranode is many times faster when compiled with MSVC, CPU usage down from 20-30% to 1-4%. This is rather interesting, because during development, my primary target was GCC, and hydranode code is optimized to work with GCC, and there's still room for further optimizations - scheduler/network handling code isn't even close to the speeds I'd like to see there. And already, with that slow code, MSVC produces so fast binaries out of it. By the time I get CPU usage down to <5% margin under heavy load with GCC, cpu usage on win32 will be non-existent, which is a Good Thing :)

What else ... the new website is nearly complete, missing only minor things and touches now, so should be lanched soon (that's what the references to buttons and design in last blog post were about - not the GUI). Speaking of GUI - yes, it's being worked on, but the work is non-visible, mostly consisting of discussions, thinking, dreaming, and so on - the typical design process. We have very high requirements for the GUI and it's features, just as we'v had for the core from the beginning.

The GUI application structure will be identical to the engine's - there will be a core application, which displays the actual dialogs, and provides an API, but does nothing else. Communication with the engine(s) is implemented in plugin(s), which use the API calls to display data. Generally, it makes sense to have only single communication-plugin loaded at a time, altough there are no restrictions for connecting same GUI to multiple cores, should one need that (not needed for 99.9% users tho). However, this application layout gives the same benefits we'v been enjoying in the core - plugins can extend the GUI w/o causing feature bloat. Keeps everything nice and modular. The future is that the majority of GUI features will be implemented by plugins. For example, media libraries, integrated media players, unpackers, file content viewers or whatever comes to mind, should be implemented by plugins.

Madcat, ZzZz

I like the way you think, I love to have applications that don't have features I don't use. Right now hydranode is running pretty fine (about one or two weeks), only thing I noticed that I can't cancel filenames with whitespaces in it (maybe it's fixed, I haven't tried for a while) and that typing "download" every time is pretty annoying (synonyms???). How about adding something like the mldonkey protocol handler for mozilla based browsers (only better :D ) to your todo-list. Adding downloads is really a hard job ;)
I'm not using the most recent core (although it's pretty recent), so if any of the things I said is already done/fixed forget that I wrote it...
btw memory usage is great too....
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?