Re: to be effcient or not to be efficient

Enrico Weigelt <[email protected]>
Newsgroups gmane.comp.multimedia.media-api
Message-ID <[email protected]>
* Steve Lhomme <[email protected]> [2004-01-07 14:03:32 +0100]:

<snip>
> Consider this :
> struct _blah {
> 	uint16 Size;
> 	uint8  FieldA;
> 	uint32 FieldB;
> 	char   FieldC[30];
> };
> 
> Now (after a few years) you realise that you need FieldA to be on 2 
> octets instead of 1. You simply can't. And you can with EBML.

You dont want to change it, since it will break existing applications
someday. Either you thing carefully on the first time and simply
use long for every int or forget it. Changing interfaces for me is a
absolute no-no-no-never-ever-in-life.

If you really _need_ something different, you still can invent a new
interface and but a little adapter between both.

<snip>
> Freaks as you say will be the major league soon. Apple already has 
> already dual on-chip CPU. Intel has HyperThreading. And I think AMD is 
> also thinking about a similar feature... That's IMO the best way to 
> continue to grow the computing power without too much problems.
I do not aggree the way, large companies tend to go - simply throwing
as much material as needed to solve the problem, but never think
too much ... (thats why HP didnt get the recent project on mobile phone
accounting running on their largest machines, while folks like me would
have solved it w/ a bunch of cheap pizza boxes ...)

Coding software for machines which are not widely available yet, is 
always a bad idea. And as already written here, many of us are using
"old" machines, but we do not want to buy new ones if we could work
with the existing ones when properly using our brain.

<snip>
> OK, so what would you use ? The output pulls the data (no lock needed) ? 
> The input pushes the data (lock needed while data are not needed yet) ? 
> How is seeking handled ? When you're in the middle of decoding an I 
> frame for example ?

hmm, we would use plain fifo structures, which both modules are 
connected to. 

struct VIDEO_FIFO
{
    long in_ptr;
    long out_ptr;
    long buflen;
    
    (struct VIDEO_FRAME*) buffer[];
};

... just a short thought ...


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     [email protected]
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.