similar to: Possible inefficiency in encode.c

Hi, I'm new to Theora and would like to propose several performance optimization using advanced instructions in x86 CPUs (SSE2-SSE4.2). There are several source files in \x86 and \x86_vc which developed using inline assembler. However this cause several maintenance problems: 1) Need to sync gcc & msvc versions 2) Only 32bit environment is supported 3) No support for newer than MMX

Thank, Timothy! I add this stages. About RLE: I have one more unresolved stage. Mike Melanson wrote in "VP3 Bitstream Format..." about RLE using: "* Zigzag Ordering: After transforming and quantizing a block of samples, the samples are not in an optimal order for run length encoding. Zigzag ordering rearranges the samples to put more zeros between non-zero samples." If we pass

libswfdec/jpeg/jpeg_rgb_decoder.c | 1 - 1 files changed, 1 deletion(-) New commits: diff-tree 15ed4a69b4ffc265fe103ba79a0b60af7e42a9fa (from 2073f39bc0b0aa90f1f67def9bb3f0c6b68018ae) Author: Benjamin Otte <otte@gnome.org> Date: Wed Apr 18 10:47:06 2007 +0200 remove leftover debugging statement diff --git a/libswfdec/jpeg/jpeg_rgb_decoder.c b/libswfdec/jpeg/jpeg_rgb_decoder.c

Good day! I create diagram of encoder process. Using it i create implementation of encoder in FPGA (Xilinx/Altera). Please critique it. Is there missing stages? Here is blog http://developer-fpga.blogspot.com/ Here is picture of encoding stage 1 https://lh4.googleusercontent.com/-NV8o9DG3jvE/TYjYXr-dYGI/AAAAAAAAAos/U06O-YvhSI0/s1600/stage1.jpg Here is picture of encoding stage 2

Hello, I'm attaching IDCT MMX patch. I reused IDCT from theora-a3-MMXd.zip. It should work on 64bit X86 platform too. Here is most used functions when playing video with jet aircrafts (gripen) Ogg logical stream 310b2968 is Theora 720x480 29.97 fps video Encoded frame content is 720x480 with 0x0 offset I can play this video with like 200-300 frame drops on Athlon XP 1700+ CPU load (with

Hi, is there a good concept to lower the quality of a Theora stream without completely reencoding it? For example to make a lower bitrate stream out of a higher bitrate stream on the fly on some sort of proxy server. I am thinking about something like requantization. If you think requantization is also the best (or the only) option for Theora please let me know. Kind regards, Franz

This is v3 of my disk series. What were previously patches 01-06 have been applied. These are the tested and updated remainder, addressing the previous comments. 1 Preparatory work. 2-4 The new parser and its documentation. 5-6 Replace old parsers with calls to the new one. 7-8 Two features, one of them essential. 9 Basic test suite for disk string parsing, as adhoc script.

I was looking over Function.cpp and saw that for every call to Intrinsic::getName, the entire intrinsic table (about a thousand references to strings) gets copied over for the initialization of Table. Is there a reason for why this is done, or would it be better for Table to be static, so that this initialization only happens on the first call? Perhaps this is optimized away for the release build,

In do_matrix in src/array.c there is a type switch containing : case LGLSXP : for (i = 0; i < nr; i++) for (j = 0; j < nc; j++) LOGICAL(ans)[i + j * NR] = NA_LOGICAL; That seems page inefficient, iiuc. Think it should be : case LGLSXP : for (j = 0; j < nc; j++) for (i = 0; i < nr; i++) LOGICAL(ans)[i + j * NR] = NA_LOGICAL; or more simply : case

On 04/02/2019 9:20 a.m., Radford Neal wrote: >>> I think you might want to just delete the definition of $.data.frame, >>> reverting to the situation before R-3.1.0. >> >> I imagine the cause is that the list version is done in C code rather >> than R code (i.e. there's no R function `$.list`). So an alternative >> solution would be to also implement

Hi, Can someone technically explain, why does it take so long with loops in R? Thanks, Vehbi Sinan Tunalioglu

>>>>> peter dalgaard >>>>> on Mon, 4 Feb 2019 16:48:12 +0100 writes: > Does either of you have a patch against current R-devel? > I tried the obvious, but the build dies with > building package 'tools' > all.R is unchanged > ../../../../library/tools/libs/x86_64/tools.so is unchanged > installing

Hi Chris, This is a good idea and I started thinking in that direction already. But what I don't quite understand the TFs, how TFs are formed and which rules they should obey to. For example now: > PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the > TokenFactor node by SelectionDAGLowering::getRoot called from the >

> > I think you might want to just delete the definition of $.data.frame, > > reverting to the situation before R-3.1.0. > > I imagine the cause is that the list version is done in C code rather > than R code (i.e. there's no R function `$.list`). So an alternative > solution would be to also implement `$.data.frame` in the underlying C > code. This won't

I have a new problem: Register RBP is used in a function foo. (I am not allocating RBP to any virtual register, the instances of RBP in function foo are in the machine code when my register allocator starts.) Function foo calls function bar. Register RBP is not saved across the call, though it is live after the call. Function bar includes a virtual register. The code that I'm using to

Hi, While profiling LLVM using my test-cases with huge MBBs, I noticed that FoldingSetNodeID operations (ComputeHash,insertion,etc) may become really inefficient for the nodes, which have very many operands. I can give you an example of what is meant by "very many". In my test-case (you can fetch it from here http://llvm.org/bugs/attachment.cgi?id=1275), which is just one HUGE MBB

Hi Dan, Thanks for commenting on this topic. See my comments in-line. ----- Ursprüngliche Mail ---- > Von: Dan Gohman <gohman at apple.com> > An: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Gesendet: Mittwoch, den 30. April 2008, 21:38:26 Uhr > Betreff: Re: [LLVMdev] FoldingSetNodeID operations inefficiency > > > On Apr 28, 2008, at 6:21 AM, Roman

While doing some performance testing with the new version of pqR (see pqR-project.org), I've encountered an extreme, and quite unnecessary, inefficiency in the current R Core implementation of R, which I think you might want to correct. The inefficiency is in access to columns of a data frame, as in expressions such as df$col[i], which I think are very common (the alternatives of

Hi Chris, Your were totally right with your suggestion. I have implemented the code that : a) does not merge multiple TokenFactor nodes in the DAGCombiner::visitTokenFactor(), if the resulting TF node would contain more than 64 operands. b) produces a bunch of TokenFactor nodes with at most 64 operands, instead of one huge TokenFactor in the SelectionDAGLowering::getRoot(). If we have n

I have a file for which clang-7 takes over 2 hours to compile with -O3. For the same file, clang-5 takes less than 2 minutes (which is also high IMHO). I will try to create a test case (but it is pretty simple, it only contains initializations of many arrays of structs where the structs are of the following form: struct Foo { EnumType1 e1; // there are 700+ enum labels std::string s1;