similar to: Proof-of-concept multithreaded FLAC encoder (take 2)

Hey FLAC devs, I managed to hack out a proof-of-concept multithreaded FLAC encoder based on the example libFLAC one. It turned out to be fairly straightforward to get near-linear speedup; I can encode a 636 MB wave file in 6.8s with 8 threads on an 8-core 3.0 GHz Xeon vs. 31.4s with a single thread. Basically I mmap() the input file, divide up the mmap()ed region into nearly equal pieces,

On Tue, May 6, 2008 at 2:03 PM, Brian Willoughby <brianw at sounds.wa.com> wrote: > Frederick, > > This is great news! Thanks for your effort. > > Your proof-of-concept raises a few questions for me: > > 1) I know that the ratio of uncompressed to compressed data is > unpredictable, but I never really considered whether the input block size or > the output

On May 6, 2008, at 14:20, Frederick Akalin wrote: > On Tue, May 6, 2008 at 2:03 PM, Brian Willoughby > <brianw at sounds.wa.com> wrote: >> 3) Do you accelerate decode as well as encode? I'm thinking that >> the >> variable block size would require each thread to scan its block >> for the >> start of a new block header, and also continue

Frederick, This is great news! Thanks for your effort. Your proof-of-concept raises a few questions for me: 1) I know that the ratio of uncompressed to compressed data is unpredictable, but I never really considered whether the input block size or the output block size is constant. I'm assuming that if you're breaking the uncompressed input file into multiple pieces, then the

On Tue, May 6, 2008 at 4:52 PM, Christopher Peplin <chris.peplin at rhubarbtech.com> wrote: > Along the same line as Frederick, myself and another university student were able to implement a multi threaded FLAC > encoder, but using Intel's Threading Building Blocks (TBB) package. We saw similar near-linear speedup. Great! Your approach is better in that it bounds the memory

I'm not aware of any other attempts, and there have never been official plans. It's difficult to partition input for opus at anything other than the track level, because of the way the decoder derives its adaptive state from recently-seen audio. I guess cutting together streams with at least an 80ms overlap wouldn't glitch too much? You could probably do something to try different

>>> Ralph Giles <giles at thaumas.net> schrieb am 30.03.2020 um 23:17 in Nachricht <11930_1585603054_5E8261ED_11930_50_1_c110a52d-de95-3bbb-35b2-eca12c79f143 at thaum s.net>: > I'm not aware of any other attempts, and there have never been official > plans. It's difficult to partition input for opus at anything other than > the track level, because of the way

Hello, I have some code that encodes PCM data into a vorbis stream, using the workflow shown in http://www.xiph.org/vorbis/doc/libvorbis/overview.html. By analyzing that process with valgrind/cachegrind I found out that 95% of the time used for encoding is spent in the function "vorbis_analysis(&vb, 0)". My question now is: would it be technically possible to parallelize this? I

Chandler Carruth <chandlerc at google.com> writes: > Having thought a bit about the best strategy to solve this, I think we should > use a tradeoff of memory to reduce contention. I don't really like any of the > other options as much, if we can get that one to work. Here is my specific > suggestion: > > On Thu, Apr 17, 2014 at 5:21 AM, Kostya Serebryany <kcc at

Greetings all, First of all, a disclaimer: Please forgive my horrible assembly code. This is just a quick munging of code to achieve x86 versus x86_64 detection within pxelinux. So please look at it as a proof of concept and not a real piece of code. :) For example it only works on pxelinux and has no thought for extending it beyond simple x86 versus x86_64 architectures. I had the need for

2010/10/21 Jason Kim <jasonwkim at google.com>: > Of the 45 remaining, there are 4 interesting uses in MCAsmStreamer.cpp > - (I suppose for emitting data constants in a cross platform manner) > The other remaining uses are in AsmPrinter, again to do cross platform things. > It seems a bit strange to use a high level hammer to do ballpeen > work..... But when in Rome.... :-)

OK, after reading the docs I have some extra comments (and an updated patch). *) To support per section or per symbol attributes we would have to move this to the processing done in the end of the file. Lets not do this right now. *) We don't currently use any string attributes, so I did not implement them. *) Having an attribute emitter class is a nice way to separate the job of creating the

I also noticed that we were trying to optimize the output of 41 bytes of data :-) The attached patch is similar to the previous one but drops the API changes by just accumulating the attributes locally before outputting them. Cheers, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: attrs.patch Type: text/x-patch Size: 12333 bytes Desc: not available URL:

I work for a multi-billion dollar international organization currently using Novell technology for F&P/Directory/etc... A project has just arisen to develop several potential replacement proofs of concept. Several solutions are being evaluated, including: * Microsoft CIFS * Some NAS device using AD or eDirectory * Linux/Samba I was chosen as part of the Linux/Samba team and I'd like to

Honestly, I don't see the motivation for this. There are many similar projects that are mature, so my feedback would be: don't reinvent the wheel and contribute to those. I?aki El vie., 14 jun. 2019 3:18, Abby Spurdle <spurdle.a at gmail.com> escribi?: > I thought that I'd get more feedback. > But it's ok, I understand. > > I wanted to note that I've moved

On Fri, Jun 14, 2019 at 7:24 PM I?aki Ucar <iucar at fedoraproject.org> wrote: > > There are many similar projects that are mature I'm not sure what projects you're referring to. If we create some constraints: (1) Internal systems consoles (*plural*). Rules out most things. Noting that many tools are designed to bypass the console. (2) Modern user interface. Rules out Vim

2010/10/21 Jason Kim <jasonwkim at google.com>: > That is exactly what I need - I need a nice MC way to output a at > least two different 4 byte size fields after all of the blobs in the > .ARM.attributes are sent out. Hi Jason, If I got it right, you need to write to the attributes section after you have moved out to print the rest of the file. I can't think of an example

On Sat, 15 Jun 2019 at 01:24, Abby Spurdle <spurdle.a at gmail.com> wrote: > > None of the tools that I've looked at satisfy these constraints. > But if you know of some, I'd like to know... And I would consider contributing... What about Atom, VS Code and the like? Or what about taking a project that meets most of the constraints and pushing to cover all of them, or even

On Thu, Oct 21, 2010 at 11:42 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Also what is the preferred method for MC way of setting out subsection >> sizes after the fact? I am guessing I need to use an MCFixup? >> How do I get an MCExpr to evaluate a method for the subsection size? >> Is there an equivalent use in the places using MCFixup? >>

On 30/3/20 23:17, Ralph Giles wrote: > I'm not aware of any other attempts, and there have never been official > plans. It's difficult to partition input for opus at anything other than > the track level, because of the way the decoder derives its adaptive > state from recently-seen audio. I guess cutting together streams with at > least an 80ms overlap wouldn't glitch