[Flac-dev] Re: multiple core support

[Harry Sack]

2007/9/8, Brian Willoughby <brianw at sounds.wa.com>:
>
> Harry,
>
> You assume that the only way to use FLAC is the way that you are using it,
> by converting one file format to another.  That's not the only way to use
> FLAC.  The most important uses of FLAC are for internet streaming radio or
> hand-held digital audio players.  Both of these prominent uses are not
> really file based, but are stream based.  It makes perfect sense for the
> core of FLAC to be stream based.  It makes the code small and portable to
> any platform, no matter how limited.
>


1) I never said this is the only way to use it: you put those words in my
mouth, I never told this to anybody :)
I also didn't say the fact that the API is based on streams is bad! I only
say it's not a good choice if you want to support multiple threads ...
Please read carefully what I write :)

Besides, the API has support for seekable streams and files.
>
> The big issue here is that you actually believe it is possible to support
> multiple processors and, further, that there would be an advantage to this.
> Those are both really big assumptions.  I don't think anyone else, besides
> you, believes that it is possible or desirable for the FLAC codec to be
> multithreaded.
>


2) you really show you have no good knowledge about programming. There are
several codecs out there that  try to use multiple cores.
To give a concrete example: http://www.lame-mt.com/
Here is the prove there is a HUGE performance boost:

'The output of this multi-threaded version, based on LAME 3.97 alpha, is 1:1
bit compatible with the original version and it gains *~1.16x speedup* when
Constant Bit Rate (CBR) or Average Bit Rate (ABR) models are used and *~1.30
speedup* when Variable Bit Rate (VBR) mode is used on SMT platforms and >
1.45x on SMP systems.'

If you say it can't have no speed improvement, then you prove you don't know
a thing about programming.
I will laugh at you when 8 cores wille be standard in all pc's and you still
will say the same :)

Harry, you've sent 90 to 100 messages to these mailing lists asking about
> whether FLAC supports every possible feature that a given piece of software
> or an audio format could have.  If you read about a feature someone else,
> you come here asking when FLAC will support that feature, or why not,
> without any idea of why it would even be good, or even possible.
>


3) I told you multiple thread support is possible, I gave you an real-life
example of the LAME encoder above.
I also gave reasons why it would be better: faster encoding speeds, ...
Besides that: you can't decide if I send messages to this list or not, so
don't *even* talk about that!



You don't seem to understand that it is not possible to put every feature
> into every program, not just because of development resource constraints,
> but also because certain features are mutually exclusive.  Certain features
> make other features impossible, or at least undesirable.  It simply isn't
> possible to do some of the things you're asking for, and I am actually
> surprised that you don't understand why they are impossible.  You have
> basically shown a lack of solid understanding of formats, mathematics,
> programming, and logic.
>


says the guy who tells me supporting multiple threads in the encoding phase
of an encoder is impossible and will give NO performance boost (I point you
out to LAME MT again that proves you're wrong) ...

There is a popular saying: "The is no such thing as a stupid question."
> Well, Harry, you're the first person I've experienced who thoroughly
> challenges that statement.
>


And you are the first person who thinks he is mister-knows-it-all but gives
EXTREME funny and incorrect statements like:
- 'multiple core support won't give a performance boost'
- 'it's impossible to implement multiple threads in an audio encoder'

I recommend you to study IT (like I did) and get your master's degree and
after that maybe your PhD.
We'll talk again then when you accomplished this :)

best regards,
Harry

Brian W.
>
>
> On Sep 8, 2007, at 06:02, Harry Sack wrote:
>
> 2007/9/8, Josh Coalson <xflac at yahoo.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? 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
>
> 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?
>
> thx
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20070909/4d78b9a6/attachment-0001.html