[FFmpeg-devel] GSoC with FFMpeg waht a combination!

[Michael Niedermayer]

On Tue, Mar 25, 2008 at 12:16:12AM +0200, Uoti Urpala wrote:
> On Mon, 2008-03-24 at 22:47 +0100, Michael Niedermayer wrote:
> > On Mon, Mar 24, 2008 at 11:18:00PM +0200, Uoti Urpala wrote:
> > > That's a fucked up table... there are 32 KiB of pointers to strings and
> > > 32 KiB of actual strings (I assume you meant Ki, not k)? Assuming 4-byte
> > 
> > I didnt mean kiddy byte no.
> 
> Well no OS I know reads data in 4000 byte blocks...

No, but some do read in 4kb blocks. Iam not using the SI system of prefixes
but rather the standard binary 1024 based ones. Which i am sure is obvious to
everyone.


> 
> >  And gettext needs more than 7 byte to store a
> > 2 byte index IIRC. Complain to them for the fucked up format ...
> 
> WTF does the gettext implementation have to do with it? That was about
> the behavior of binary search, not the gettext implementation (which can
> use hashes). Your hash version was not the gettext hash implementation
> either.

This thread was about gettext vs. alternatives. None of the alternatives
discussed, would use a binary search. Also none of the gettext files i
ve seen actually used a hashtable.
So the comparission here being "what gettext does in reality" vs. "what
a proper written hash table based system would do".

One surely could compare the gettext hash system against the proposed
hash system, this though will need about 3 times as many seeks due to
the way the data is fragmented.
Of course you will now argue how the data can be reordered at runtime.
And then i will refer you back to the list of issues this has like
needing extra swap space as it looses the file backing the data, ...


Anyway, if you were not arguing about gettext as you indicate in your 
"WTF does the gettext implementation have to do with it?"
then i do not see what you are arguing about at all. After all this
thread was about gettext being a bad choice. And you where trolling
that gettext would be all so great.


> 
> > > Getting to 2 seeks on average would cost extra space though, as you'd
> > > need to store enough information in each hash table cell to be able to
> > > verify whether it's the correct one without extra seeks (and this would
> > > be wasted in the unused cells).
> > 
> > This discussion is very tireing, it does waste maybe 4 bit on average and
> > maybe it ends uo needing 2.1 seeks on average.
> > Werent you just arguing a moment ago that 200 bits for an average string
> > didint matter.
> > Or is it that you just count bits in my design diferently? Could you spare
> > me of this trolling please!
> 
> You were the one who argued for minimum space usage.

No i argued for not wasting space unneccessarily.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080325/ffcd1384/attachment.pgp>