List Info

Thread: Re: Re: multiple core support
Re: Re: multiple core support
country flaguser name
United States		 2007-09-09 13:28:10 
--- Harry Sack <tranzedudegmail.com> wrote:
> 2007/9/8, Josh Coalson <xflacyahoo.com>:
> >
> > it actually is complicated.  the libFLAC api is
not suited to a
> > multithreaded design because the i/o is
stream-based, not file-
> > based.  flac(.exe) is the file-based wrapper
around libFLAC that
> > allows it to work on files.  the way libFLAC
buffers data is also
> > impossible to parallelize without significantly
changing the api.
> 
> why was this approach used?

because the tradeoffs I described required for arbitrarily
parallel
encoding significantly complicate the api and
implementation.
libFLAC was not design for multicode file encoding on PCs,
it is a
reference design that is also being used in embedded devices
running
<100MHz, low memory, all kinds of different OSes, etc.

> The API design seems to me not very smart
> because it's not flexible and you're stuck in the
future (like now
> for multiple core support)
>
> I don't see any reason why you wouldn't make it all
based on files
> and not on streams :s It's just a major disavantage in
my opinion

an api cannot be all things to everyone.  you keep making
this
assertion but if you actually tried to implement it (and I
hope
you will) the problems we are all bringing up will quickly
become
obvious.

your own lame-mt example is not an incremental improvement
but a
significant rewrite of lame (and also does not have nearly
the
performance advantage of process-level parallelism, see
http://www.hydrogenaudio.org/forums/index.php?showt
opic=50862)

> > it would take a specialty file-based encoder using
an independent
> > frame encoder to do and even that is not trivial.
> 
> so we can assume that those API changes will never come
and the flac
> encoder will never have multiple core support?

you can assume libFLAC will probably not have it.  if you
can modify
libFLAC to make a multithreaded encoder like flac-mt that
would be
neat and probably useful to some people.  until that time
there is
not much point repeating the same assertions which are just
going to
aggravate people.

Josh



       
____________________________________________________________
________________________
Building a website is a piece of cake. Yahoo! Small Business
gives you all the tools to get online.
http://smal
lbusiness.yahoo.com/webhosting 
_______________________________________________
Flac-dev mailing list
Flac-devxiph.org
http:
//lists.xiph.org/mailman/listinfo/flac-dev
Re: Re: multiple core support
user name
 2007-09-10 07:18:22 

  


  

    

2007/9/9, Josh Coalson < xflacyahoo.com">xflacyahoo.com>:

--- Harry Sack < tranzedudegmail.com">tranzedudegmail.com> wrote:
>; 2007/9/8, Josh Coalson < xflacyahoo.com">xflacyahoo.com>:
> >
> > it actually is complicated. &nbsp;the libFLAC api is not suited to a

> > multithreaded design because the i/o is stream-based, not file-
> > based.&nbsp; flac(.exe) is the file-based wrapper around libFLAC that
> > allows it to work on files.&nbsp; the way libFLAC buffers data is also

>; > impossible to parallelize without significantly changing the api.
>
> why was this approach used?

because the tradeoffs I described required for arbitrarily parallel
encoding significantly complicate the api and implementation.

libFLAC was not design for multicode file encoding on PCs, it is a
reference design that is also being used in embedded devices running
&lt;100MHz, low memory, all kinds of different OSes, etc.



euh  Just make a flag or something in the api that enables the code for low cpu power devices and/or streaming and disable this when encoding on fast pc (so no streaming)? So it uses file based code then for encoding of files on pc's with multiple cpu's and stream based code for all other devices and streaming 

Then you have both in the API! 

> The API design seems to me not very smart

&gt; because it's not flexible and you're stuck in the future (like now
> for multiple core support)
&gt;
> I don't see any reason why you wouldn';t make it all based on files
> and not on streams :s It's just a major disavantage in my opinion


an api cannot be all things to everyone.&nbsp; 


sure it can: you just have to make some different cases (low cpu power device/streaming or multi-core cpu) and call the apprioprate functions 






you keep making this
assertion but if you actually tried to implement it (and I hope

you will) the problems we are all bringing up will quickly become
obvious.

your own lame-mt example is not an incremental improvement but a
significant rewrite of lame (and also does not have nearly the

performance advantage of process-level parallelism, see
http://www.hydrogenaudio.org/forums/index.php?showtopic=50862)

It's multi-threaded and that's what I mean: people here say an audio codec can't be written multi-threaded and it will give no performance boost:

1) that's false: se LAME MT
2) performance boost up to 30%: see LAME MT again

For very large files you must wait not so long before it's encoded vs. the original LAME. 


> > it would take a specialty file-based encoder using an independent
> > frame encoder to do and even that is not trivial.
&gt;
> so we can assume that those API changes will never come and the flac

>; encoder will never have multiple core support?

you can assume libFLAC will probably not have it. &nbsp;if you can modify
libFLAC to make a multithreaded encoder like flac-mt that would be
neat and probably useful to some people.&nbsp; until that time there is

not much point repeating the same assertions which are just going to
aggravate people.

Josh




____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.

http://smallbusiness.yahoo.com/webhosting




  

  
  
   
     
    






 [1-2]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )