Sorry about not replying sooner, but we have chatted about it on IRC
which has made me slack.
On Tue, 2007-02-20 at 23:45 +1100, Brett Nash wrote:
<snip>
> This affects no other type in tp03, so existing code can continue to be
> used for everything _but_ strings. Newly written code can take
> advantage of the stronger guarantees.
tp03 is "frozen", so it won't be added to tp03. tp04 is suppose to be an
incremental increase over tp03 so changing a fundamental type doesn't
seem the right time.
tp01->tp02 was almost a complete overhaul (hence why we where able to
make the change). We made plenty of other radical changes at the same
time.
> Other advantages are allowing better use of data in the message - it
> can be read and directly responded too, which is particularly useful for
> smaller messages in certain cases. Essentially at the moment the entire
> message needs to be copied out piece-by-piece. This allows either block
> copying or direct access to relevant pieces. Also processing the header
> of message can now be done in place (since fragmentation won't happen
> below a 4bytes).
I'm not sure I understand this point, care to explain further?
<snip>
tp04 has support for "filter negotiation" I say that we add a new filter
type called "word aligned" filter. This would pad strings out so that
they always aligned with word boundaries. However, for this to be useful
it needs to be a required filter.
Another argument is that it would decrease server load, however I think
most servers will be bound by the backend speed and not protocol
decoding speed.
The next question is, you have already implemented the protocol and is
it going to be worth adding when the gains are lost in the noise of most
other languages (such as Python, Ruby, C# or Java).
So far the only real advantages I see are:
- easy of maintenance of the C (and possible C++) libraries
- possibly small speed increases
Disadvantages
- Breaks backwards compatibility with tp03/tp02 strings
- Requires extra slow level code be written for the Ruby/Python/C++
libraries
- Extra bandwidth requirements
Why not just define a macro? Something like,
inline int32 my_ntoh(void* p) {
int32 i;
memcpy(p, &i, sizeof(int32));
return ntoh(i);
}
inline my_hton(int32* i, void p) {
int32 j = hton(*i);
memcpy(&j, p, sizeof(int32));
}
Then you don't have memcpy's anywhere except in those functions. I'm
sure you could even reduce those to like really fast ASM code or
something ;)
This isn't a definite "NO", just what I'm pondering at 3am in the
morning. What do others think?
Tim Ansell
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
