Street Chaman wrote:
Thanks to everyone who read my question; here some precisions:
Actually, my soft is a kind of interactive filter: it takes a lot of imput parameters (from keyboard at the moment, but as soon as i've understood how it works, i will increase the number of supported io devices); treats it in a particular way and produces an output. This 'particular way' requires a lot of clock cycle, so speed is my first problem; (that's part of reason why everything is directly written in assembly). I've already buffered input and output, but only as far at it was possible: since loop (X) input could affect loop (X-1) general data manipulation, and change output, it must be detected quickly. The time needed to read/write is still to long. When CPU is waiting on some new data, he cannot preform any other operation, and freezes data manipultion; that's why I'm looking for a new way to in/output the soft...
I've found out in syscall.master the aio_read/write call. Man page says operation is asynchronous, so it returns quite immediatly after enqueuing the io thread. Could that be a solution ? Or back to kernel module (by the way: is it possible to write on in assembly) ?
I don't think you're supplying us with enough information here to give you a definitive answer. You mention reading from the keyboard but then you say that it can't read/write fast enough? You must be one hellofa typist. What are you reading/writing from? Keyboard? Disks? Reading/writing to disks is going to be slow, the kernel buffer caches will help though. Why is it so critical that syscalls return faster than they are? Are you attempting to do real-time computing? Are you doing any kind of threading? Is it even physically possible to return faster on the IO device you are wishing to access?
You mention doing it all in assembly, have you tried coding the same thing in C with a select few (as someone else mentioned) critical paths written in assembly? You could then more easily make use of multi-threading the application on an SMP box. However, this is all blind conjecture because we have relatively little information about what you are trying to accomplish.
-- Ryan Sommers [EMAIL PROTECTED] _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
