>On Sun, Nov 03, 2002 at 06:50:54PM -0600, Robert Carroll wrote: >> I think alot of problems with freenet are performance related. The network as a whole would benefit from faster freenet code. Perhaps the developers should consider converting some java methods into native methods. Given the 90/10 rule, a small number of converted methods could yield a huge performance increase. I'm not suggesting that java support should be dropped, but this effort would be paralell to the main java codebase. Unsupported platforms could still use the java methods. This probably wouldn't be a big deal to transients (directly anyway), but it would be a HUGE benefit to the permanent nodes which are the backbone of freenet. >This is incorrect. The node has numerous major network level problems at >the moment - inserting a file on one node at HTL 25 and then getting a >DataNotFound at HTL 25 on another node, is not a good sign. Mostly this >is due to growing pains and old versions of the node though, hopefully. > >Eventually, we may make fred use nonblocking I/O; this will drastically >reduce the number of threads needed, but it will be a lot of work and it >is not a major priority because there are easier things with a bigger >impact to do first.
It seems to me a lot of the cpu-sucking just comes from os process-switching-overhead. I'm seeing this problem with a project of mine that makes heavy use of threads. It's not actually doing much work, but sucking up the cpu anyhow. I remember having a vm once that actually mapped java threads to linux pthreads (or something), not processes. Would that be a workable/functioning workaround to the problem? I tried to try IBM jre 14 (since I think it was an IBM vm that did the thread-mapping), but couldn't get it to work (exec: cannot execute binary). probably libs missing, but dunno which. Anybody got a hint for me? Does anybody use a vm that does this? Am I off-track with the concept? I dont like that jni approach by the way, after all, fred is a "reference"-daemon and it should run anywhere. If you want a perfomance-oriented version, I would suggest to reimplement completely in portable c++ or something. cheers, nick _______________________________________________ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
