[Vortex] Windows binary distribution issues

[Francis Brosnan Blazquez]

El mar, 20-06-2006 a las 11:56 +0000, Joe Dalton escribió:
> Francis,

Hi Joe,

>  Thanks for having a look at this. I'll give it another try ;-)

Ok.

>  I have another question, more related to performance.
>  I've tried the library on a dual opteron box running Linux.
>  Implementing the null echo profile, I see very poor numbers
>  of 80ms for a basic null_echo_trip - interacting with beepcore java
>  things are even worse ~100ms.
>  Looking further, it seems that most of the time is spent in the
>  synchronization between the reader, the writer, the sequencer and
>  the threadpool. I'm not sure, but I think most of it is spent in the 
>  use of the asyncqueue push and pop (essentially the pop I guess).
>  Have you try running gprof on the library?
>  I think some improvements can be achieved by removing unecessary
>  synchro here, the threadpool should be enough to do the work.
>  What do you think?

I think you are mostly right ;-) Let's put things into perspective.

Currently, as you may know, there is not too much work out there on
producing a complete, full featured open source BEEP framework. 

At this moment we are working on producing more features that would make
more people to produce BEEP based applications (and to attract people
like you), rather than working on Vortex Library performance. 

We have already received requests to start *right now* performance
scalling to the library. They are right, however, it is really required
to have some pieces finished and fully working. We strongly believe it
is not time for performance.

Our plans is to start the performance scalling once done the XML-RPC
protocol compiler (it is really near), a TUNNEL server (a BEEP proxy)
and a client TUNNEL support for the library.

In the other hand, this doesn't stop you (and anybody) to start helping
with the Vortex Library performance improvement. Feel free to propose
any patch you migh produce that improves current performance. We'll
really appreciate it!

Cheers!

PS: Here is an additional insight to the one you have found:

* A bottle neck to disable at the Vortex Library code is to start using
a proper thread oriented memory allocator, something based on [1].
Currently, using malloc directly is a *huge* problem [2] because every
thread must be blocked from each other until its memory request is
satisfied.

[1] 
http://www.usenix.org/publications/library/proceedings/bos94/bonwick.html

[2]
http://developers.sun.com/solaris/articles/multiproc/multiproc.html

>  
>  Best Regards,
>  Joe. 
-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.