search for: file_read

...the tests caught my eye. 164.gzip ran about 25% slower on my system using LLVM versus gcc. As you said, source level debugging information wasn't available for the LLVM binary but from looking at a profile of the code, there are two functions that take up a moderate amount of time (zip and file_read) in the LLVM binary but these functions are not in the profile of the gcc code. Is it likely that gcc would have inlined these? file_read is relatively small, but zip is a little bigger. I tried to test this theory by manually editing the gzip code to inline those two functions, eg inline int...

On Sun, 2 May 2004, Patrick Flanagan wrote: > Is there anything special flagwise that I would need to specify to tell > it to include symbol and debug information? I've tried specifying -g > but this information still doesn't seem to be included. A quick copy of > the build of one of the tests to make sure I've got the flags right: Nope. Right now LLVM doesn't have

...w what is the minimum file block size that I must consider. I red,of course, the example that exist in the speex manual, however I have some doubt. I got the FRAME_SIZE from the function /* Get frame size */ speex_decoder_ctl(state, SPEEX_GET_FRAME_SIZE, &nbBytes); repeat lb = file_read(&file, nbBytes, (void *)cbits); /*Copy the data into the bit-stream struct*/ speex_bits_read_from(&bits, cbits, nbBytes); /*Decode the data*/ speex_decode(state, &bits, output); until EOF (I get the number 160) that I use it in my file_read function to get a block o...

Dear Ralph Thank you for your info. My file_read() function only get a specified number (nbBytes) of bytes from the .ogg file and store it in cbits, nothing else lb = file_read(&file, nbBytes, (void *)cbits); Unfortunately I have only 32K (first section) + 8 (second section) = 40 Kbyte of RAM to do all, including the file system management...

...cement on*/ tmp=1; speex_decoder_ctl(state, SPEEX_SET_ENH, &tmp); /* Get frame size */ speex_decoder_ctl(state, SPEEX_GET_FRAME_SIZE, &nbBytes); /*Initialization of the structure that holds the bits*/ speex_bits_init(&bits); do { lb = file_read(&file, nbBytes, (void *)cbits); /*Copy the data into the bit-stream struct*/ speex_bits_read_from(&bits, cbits, nbBytes); /*Decode the data*/ speex_decode(state, &bits, output); /* now I reder the block */ render...

> >> Just to make sure I understand how LLVM works, got a few >> clarifications: >> >> 1. The ppc code I'm generating with the -native-cbe is static, >> correct? > > Yes, it's purely static with the -native-cbe or -native options. Is there anything special flagwise that I would need to specify to tell it to include symbol and debug information?

...n my > system using LLVM versus gcc. Hrm, I really want to figure this out! > As you said, source level debugging information wasn't available for the > LLVM binary but from looking at a profile of the code, there are two > functions that take up a moderate amount of time (zip and file_read) in > the LLVM binary but these functions are not in the profile of the gcc > code. Is it likely that gcc would have inlined these? It's quite possible. The best way to check is to look at the .s file produced by GCC and see if they are there. Note that GCC is much more aggressive abou...

...sive codes substantially. > What is the rationale for doing the llvm code -> c backend code -> compile that thing anyway? If the person specifies that -native-cbe, why not just compile the code as is? >> inlining stuff > I did play around with the inlining threshold to make file_read and zip get inlined in more spots. This didn't make any difference though, so the main problem seems to be the loops as you pointed out in last email. Wouldn't this be a non-issue if the -native-cbe flag just meant compile the code given rather than going through llvm code and the c ba...

...is doing the join in 6 secs, and a USB 1.1 bios is giong at around 30 secs. Earlier my times were about 45sec and 2min 30sec respectively. Part of the optimization has to do with libfat's cache and the other with synchronizing read block size with that of gzip's buffer reads. The vanilla file_read method in syslinux does a "cached" read which goes thru 2 memcpy's on every read, which is useless imo for a bootloader, since most of the reads are to load big files into the memory, and hopefully are read in chunks of atleast or bigger than MAXBLOCK size. Other improvements in this...

Hello everyone: After I played with Rspec for three months, I realized a weird behavior of mocking ruby classes (e.g. File). Please let me post a sample code before I point out the problems: #file_reader.rb (to be tested) class FileReader def do_read File.read(''asd.txt'') end end #file_reader_spec.rb describe FileReader, "do_read" do it "should throw File Not Found on non-existent file" do reader = FileReader.new() lambda...

On Wed, 5 May 2004, Patrick Flanagan wrote: > >> and I'm not convinced that GCC is doing a very good job (ie, without > >> syntactic loops). > > > > Yup, this is EXACTLY what is going on. > > Interesting. Now that you mention it, I do recall thinking the loops > that llvm generated looked a bit different than the gcc loops. I'll go > back and take

These changes are based on Jason's latest hmm branch. Patch 1 was previously posted here [1] but was dropped from the orginal series. Hopefully, the tests will reduce concerns about edge conditions. I'm sure more tests could be usefully added but I thought this was a good starting point. [1] https://lore.kernel.org/linux-mm/20190726005650.2566-6-rcampbell at nvidia.com/ Ralph Campbell

This series adds new functions to the mmu interval notifier API to allow device drivers with MMUs to dynamically mirror a process' page tables based on device faults and invalidation callbacks. The Nouveau driver is updated to use the extended API and a set of stand alone self tests is added to help validate and maintain correctness. The patches are based on linux-5.5.0-rc6 and are for