search for: reseri

Displaying 6 results from an estimated 6 matches for "reseri".

Did you mean: reser
2010 Nov 29
0
[LLVMdev] LLVM Inliner
...uild by avoiding having to do simple optimizations again. 2. At LTO time, the bottom-up processing of the callgraph is still goodness and presents good locality (unless you have very very large SCC's). The tweak that we'd have to implement is lazy deserialization (already implemented) and reserialization to disk (which is missing). With this, you get much better memory footprint than "hold everything in memory at once". 3. To support multiple cores/machines, you break the callgraph SCC DAG into parallel chunks that can be farmed out. There is a lot of parallelism in a DAG. I...
2004 Jul 29
3
packed ogss
Hi, I've got a problem with packed OGG files taking a long time to open before they start playing. I have about 30+ OGG files that I have joined together, now the engine I am working on has its own file management and when I use the OV open_callbaks it spends a long time constantly seeking and reading in different sets of 8500 bytes inside the open_callbacks function, some time for as
2010 Nov 29
3
[LLVMdev] LLVM Inliner
On Sun, Nov 28, 2010 at 2:37 PM, Chris Lattner <clattner at apple.com> wrote: > On Nov 23, 2010, at 5:07 PM, Xinliang David Li wrote: > > Hi, I browsed the LLVM inliner implementation, and it seems there is room > for improvement. (I have not read it too carefully, so correct me if what I > observed is wrong). > > > > First the good side of the inliner -- the
2004 Oct 01
2
Newbie seeking directions
Hello everybody, I'm developing the www.polyxmass.org (GNU polyxmass) program that is a polymer sequence editor (a polymer is a thread made of concatenated monomers). I would like to code a "self-speak-out" feature for that sequence editor: the user would select a sequence region and ask that the program would "dictate" the sequence. For example, the following could be
2010 Nov 30
3
[LLVMdev] LLVM Inliner
...simple > optimizations again. > > 2. At LTO time, the bottom-up processing of the callgraph is still goodness > and presents good locality (unless you have very very large SCC's). The > tweak that we'd have to implement is lazy deserialization (already > implemented) and reserialization to disk (which is missing). With this, you > get much better memory footprint than "hold everything in memory at once". > IR is just one memory consumer. In LTO, there are also global data structures : global symtab, global type table, call graph, points-to graph, mod-r...
2004 Aug 06
14
brainfart #67453 - hyper-index
I don''t know if this has been suggested before but.. What about adding support for a bookmark or hyperlinked index? The idea is that a large compilation such as a long speech or an album would be maintained as a single file, but on playback, the player would show numerous ''tracks'' which are really just bookmarks relating to starting position of the specific part or