search for: arigo

...so complete GC programs are nontrivial. This is somewhat similar to the state of exception handling in LLVM. It would be an excellent project to provide reference implementations of these facilities. That said, the PyPy group has llvmgcroot support on a branch; you could ask Armin Rigo <arigo at tunes dot org> for details about accessing it. On his benchmarks, Armin saw an 8% speedup vs. a shadow stack. Their gcc backend still outperforms the LLVM backend, though—and llvm-gcc outperforms that further still. So perhaps those llvm-gcc GC extensions could be put to good use aft...

...> nontrivial. This is somewhat similar to the state of exception > handling in LLVM. It would be an excellent project to provide > reference implementations of these facilities. > > That said, the PyPy group has llvmgcroot support on a branch; you > could ask Armin Rigo <arigo at tunes dot org> for details about > accessing it. > > On his benchmarks, Armin saw an 8% speedup vs. a shadow stack. Their > gcc backend still outperforms the LLVM backend, though—and llvm-gcc > outperforms that further still. The second part of this is not correct. I don...

On Monday 07 January 2008 02:32:47 Gordon Henriksen wrote: > Everything described in GarbageCollection.html should now be live. Phew! > > The collectors could use a review, but they compile, have no impact > unless used, and tests would otherwise have had to be XFAILed waiting > on them. > > The ShadowStackCollector has one issue that may be of interest in that > it adds

Hello, Everyone > That said, the PyPy group has llvmgcroot support on a branch; you > could ask Armin Rigo <arigo at tunes dot org> for details about > accessing it. FYI: some status report can be seen here: http://codespeak.net/pipermail/pypy-dev/2008q1/004441.html -- WBR, Anton Korobeynikov

On Jan 7, 2008, at 10:54, Carl Friedrich Bolz wrote: > Gordon Henriksen wrote: > >> That said, the PyPy group has llvmgcroot support on a branch; you >> could ask Armin Rigo <arigo at tunes dot org> for details about >> accessing it. >> >> On his benchmarks, Armin saw an 8% speedup vs. a shadow stack. >> Their gcc backend still outperforms the LLVM backend, though—and >> llvm-gcc outperforms that further still. > > The second part...

Everything described in GarbageCollection.html should now be live. Phew! The collectors could use a review, but they compile, have no impact unless used, and tests would otherwise have had to be XFAILed waiting on them. The ShadowStackCollector has one issue that may be of interest in that it adds constant globals in a runOnFunction context. This is bad in theory, but actually is

hi everyone.. i''m a high school teacher who wrote a webapp in PHP and MySQL for my curriculum.. i use it to keep attendance, take notes per student or class and keep track of activities. i would like to soup it up and have read both the pickax and version 2 of agile web dev... now i''m starting to work and i''d like to rename columns and relationships in the database so

On Fri, 31 Oct 2003, Armin Rigo wrote: > Hello Chris, > > We have been investigating your project and the good documentation > and are very impressed. If we understood your goals correctly > this seems like a good match for our ongoing and active PyPy project, > a reimplementation of the Python language in Python. Cool. We are all big fans of Python here. :) > We'll

Hello Chris, On Sun, Nov 02, 2003 at 10:56:34AM -0600, Chris Lattner wrote: > > driving LLVM from LLVM code is closer to our needs. Is there a specific > > interface to do that? > > Sure, what exactly do you mean by driving LLVM code from LLVM? Writing LLVM code that contains calls to the LLVM framework's compilation routines. Sorry if this is a newbie question, but are

Hello Chris, On Fri, Oct 31, 2003 at 10:58:45AM -0600, Chris Lattner wrote: > These are definitely features that we plan to add, but just haven't gotten > to yet. In particular, Alkis is working on a Java front-end, which will > require similar features. In the beginning, we will probably just use a > conservative collector, eventually adding support for precise GC. Great!

Hi all, For those of you following PyPy, our next sprint has "porting to LLVM 2.0" as one of its topics. ======================================================== Vilnius/Post EuroPython PyPy Sprint 12-14th of July ======================================================== The PyPy team is sprinting at EuroPython again and we invite you to participate in our 3 day long sprint at the

Hello LLVM-ers, The next sprint of PyPy will be held in Dallas, Texas, at the PyCon conference. Most of you know about the LLVM back-end of PyPy. So far, we use mostly the static compilation features of LLVM, but as we are progressing on the JIT side we are considering starting sometime soon working on just-in-time machine code generation backends. Clearly, LLVM might prove to be a good target

Hi Reid, On Tue, Jun 21, 2005 at 11:15:22PM -0700, Reid Spencer wrote: > If you believe that variable sized structs are a feature that is missing > in LLVM, then that's another discussion. However, LLVM needs to remain > "low level" and it is unlikely such a feature would gain much traction > since a combination of existing features can accomplish the same thing. The

Hi all, We're proud to announce... ========================================== PyPy 1.0: JIT compilers for free and more ========================================== Welcome to the PyPy 1.0 release - a milestone integrating the results of four years of research, engineering, management and sprinting efforts, concluding the 28 months phase of EU co-funding! Although still not mature enough