Subject: [rohc] sample udvm bytecodes in the user guide

From: Cristian Constantin <[email-masked]>
Date: Fri, 12 May 2006 11:45:16 +0200

hi!

pls refer to 
http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-user-guide-04.txt

section: 4.1.4  DEFLATE (the other sample bytecodes have the same
behaviour described by 1. and 2. below

some questions about it:

1. what's the trick behind outputting the decompressed bytes _as soon
as_ they were decompressed (instead of otuputting when either the whole
message was decompressed or you'd overwite some previous decompressed
bytes inside your udvm memory)

2. why would such a bytecode always save itself? (like this one does at
END-MESSAGE). if it was accessed through a state it does not make much
sense to save itself again, does it?

thanks!
bye now!
cristian

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "West, Mark" <[email-masked]>
Date: Fri, 12 May 2006 10:56:36 +0100

Cristian,

Not forgetting that the user's guide code examples are just that -- examples to show how the fundamentals of different decompression algorithms could be implemented in a UDVM...  

1. it's easier!  Turning the question around: why *wouldn't* you output decompressed bytes as soon as you had them?  (As opposed to (a) checking that the message will fit in the decompression buffer; or (b) handling the over-write case explicitly.)

2. it's easier (at least, for a simple example) than adding the bytecode necessary to do separate storage of code and data.  In general, of course, it is more efficient to save bytecode separately; this is not shown in the example, though.  How to do it is left as an exercise for the reader :-)

Cheers,

Mark.

-----Original Message-----
From: Cristian Constantin [mailto:[email-masked]]
Sent: Fri 5/12/2006 10:45 AM
To: [email-masked]
Subject: [rohc] sample udvm bytecodes in the user guide
 
hi!

pls refer to 

some questions about it:

thanks!
bye now!
cristian

---

From: Cristian Constantin <[email-masked]>
Date: Fri, 12 May 2006 12:07:45 +0200

> 1. it's easier!  Turning the question around: why *wouldn't* you output decompressed bytes as soon as you had them?  (As opposed to (a) checking that the message will fit in the decompression buffe…

cristian: bec. for example running memmove, memcpy or whatever function
you have behind that output for 500 times say (sometimes for 1 byte!!)
is slower than having something that runs only once, twice per bytecode
run.

> 2. it's easier (at least, for a simple example) than adding the bytecode necessary to do separate storage of code and data.  In general, of course, it is more efficient to save bytecode separately;…

cristian: o.k. I agree. now, suppose that over 50% of the phones (devices)
which will use sigcomp will use the sample from the user guide (maybe a
little bit tweaked). the P-CSCF software has to _run_ that pretty fast;
but any optimization you'd do is useless when such a bytecode is saving
itself 100 times per second say...

thanks!
bye now!
cristian

---

From: "West, Mark" <[email-masked]>
Date: Fri, 12 May 2006 11:20:57 +0100

Hmmmm...

Surely you should implement your 'output' function based on its expected usage patterns, rather than the other way around..?  Also, the trade-off between bytecode size, complexity, and run-time is not necessarily straightforward.

With regard to your second point, I can understand your concern.  However, I don't see how you can legislate for bad implementations.  (And any implementation that just uses vanilla code from the user's guide is going to be pretty poor, frankly.)  In terms of this specific issue, I wouldn't have thought that the differential cost of hashing code + data, as opposed to just data is too big.  The bigger cost is likely to be on compression efficiency...

Cheers,

Mark.

-----Original Message-----
From: Cristian Constantin [mailto:[email-masked]]
Sent: Fri 5/12/2006 11:07 AM
To: West, Mark
Cc: [email-masked]
Subject: Re: [rohc] sample udvm bytecodes in the user guide

thanks!
bye now!
cristian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 May 2006 13:27:45 +0200

Interesting discussion.

> is slower than having something that runs only once, twice per  

I would expect much of the bytecode (which the sender gets to choose)  
would be optimized for size, not for speed.
The sender has no idea what performance characteristics the  
receiver's UDVM will have, so it would have a hard time doing the  
latter.
For an industrial strength UDVM, I'd make sure output in small pieces  
is implemented efficiently.

> itself 100 times per second say...

Apart from the fact that, as Mark said, writing good bytecode is a  
quality of implementation issue on the sender's side;
if you actually optimize common cases at the receiver: There may be  
ways to carry over optimization in a save/load pair just the same way  
you would carry them in on a state load only.

When we developed RFC 3320, our unsubstantiated hunch was that  
decompression effort times UDVM slowdown factor would be about the  
same as compression effort (which is "native", i.e., no slowdown by  
UDVM interpretation), or, in other words, that the UDVM  
interpretation overhead would be canceled out by the much simpler  
work a decompressor has to do compared to a compressor.
Were we wrong?

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 May 2006 13:30:23 +0200

On May 12 2006, at 13:27 , Carsten Bormann wrote:

> writing good bytecode is a quality of implementation issue on the  
> sender's side;

...and, I should add, there is nothing that stops senders from  
suddenly colluding to max out on cycles_per_bit; you better dimension  
your system to be able to cope with that.

Gruesse, Carsten

---

From: Cristian Constantin <[email-masked]>
Date: Wed, 17 May 2006 15:35:51 +0200

On Fri, May 12, 2006 at 01:27:45PM +0200, Carsten Bormann wrote:
> Interesting discussion.
> Mark has mostly answered it, but let my add my 0.02?:
> 

cristian: here is what I can say about this:

- on one side you have a compressor optimized for speed for a certain
  algorithm. it is written in C and you compile it for the target
  processor with a good compiler which is able to generate fast code.
  so, it is the human optimization + the automatic one performed by the
  compiler. they really sum up. (one very important point here is that
  the compiler "understands" the C code and uses several tricks to
  generate machine code which runs fast)

- on the other side, in the worst case you have:
  o  an interpreter
  o  non-optimized bytecode interpreted by the interpretor.
  say you compile the interpretor with the same C compiler for the same
  architecture; main difference is that the optimizations performed by
  the compiler on the interpretor code is not helping as much as the one
  done _directly_ on the code as in the case of the compressor. (in fact
  the compiler has no idea what this interpretor code does, so it is
  normal...)

that is why I think that comparing the speed of the two is at least
tricky. 

bye now!
cristian