Comments on: PLDI Sampler, part I http://blog.mozilla.com/dmandelin/2009/06/22/pldi-sampler/ Just another Blog.mozilla.com weblog Wed, 25 Jan 2012 23:29:35 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Chiptuning http://blog.mozilla.com/dmandelin/2009/06/22/pldi-sampler/comment-page-1/#comment-24937 Chiptuning Sat, 11 Sep 2010 20:46:49 +0000 http://blog.mozilla.com/dmandelin/2009/06/22/pldi-sampler/#comment-24937 nice post nice post

]]> By: Leo http://blog.mozilla.com/dmandelin/2009/06/22/pldi-sampler/comment-page-1/#comment-14035 Leo Sun, 26 Jul 2009 08:25:59 +0000 http://blog.mozilla.com/dmandelin/2009/06/22/pldi-sampler/#comment-14035 Ah, I meant to point out a fun paper by Michael Bond you might have seen: he annotates runtime objects with a single bit to enable probablistic reasoning of its context (e.g., allocation site, last modification site, whatever you want). I'm wondering if that might help the Hound approach. Ah, I meant to point out a fun paper by Michael Bond you might have seen: he annotates runtime objects with a single bit to enable probablistic reasoning of its context (e.g., allocation site, last modification site, whatever you want). I’m wondering if that might help the Hound approach.

]]> By: Leo http://blog.mozilla.com/dmandelin/2009/06/22/pldi-sampler/comment-page-1/#comment-14034 Leo Sun, 26 Jul 2009 08:20:55 +0000 http://blog.mozilla.com/dmandelin/2009/06/22/pldi-sampler/#comment-14034 I like the PetaBricks projects. HPC folks have been doing this for FFTs etc., so it's cool to start to see it being packaged up. It was unclear to my why it needed to be language level instead of library level. The staged information flow work seems representative of a lot of static analysis papers coming out: the analysis doesn't work precisely enough (or have all the necessary files) because the languages are dynamic, so let's offshoot a bunch to the runtime. I think my favorite form of this was the work a couple years ago on speeding up python by doing such predictions. There's an interesting space for doing global loadtime optimizations because of this even in languages like C. Staging (esp. with a range control for precision vs. static guarentees), concurrency support, and adaptivity (e.g., for IDE integration) and maybe parallelization seem to be causing a lot of traditional algorithms to be revisited. The Hound paper sounds fun. Tainting pages or objects is a very old idea -- I'm guessing their contribution is an allocation strategy that is an improvement upon similar benefits from generational collectors? I like the PetaBricks projects. HPC folks have been doing this for FFTs etc., so it’s cool to start to see it being packaged up. It was unclear to my why it needed to be language level instead of library level.

The staged information flow work seems representative of a lot of static analysis papers coming out: the analysis doesn’t work precisely enough (or have all the necessary files) because the languages are dynamic, so let’s offshoot a bunch to the runtime. I think my favorite form of this was the work a couple years ago on speeding up python by doing such predictions. There’s an interesting space for doing global loadtime optimizations because of this even in languages like C. Staging (esp. with a range control for precision vs. static guarentees), concurrency support, and adaptivity (e.g., for IDE integration) and maybe parallelization seem to be causing a lot of traditional algorithms to be revisited.

The Hound paper sounds fun. Tainting pages or objects is a very old idea — I’m guessing their contribution is an allocation strategy that is an improvement upon similar benefits from generational collectors?

]]>