Hi,
On 2017-02-10 18:18:13 +0100, Markus Nullmeier wrote:
> Well, if this thread of thought about hand-crafted JIT should be taken
> up again by someone at some point in time, I guess it could be possible
> to reuse tools that are already out there, such as "DynASM"
> ( http://luajit.org/dynasm_fe
On 12/06/16 21:40, Andres Freund wrote:
> On 2016-12-06 14:35:43 -0600, Nico Williams wrote:
>> On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote:
>>> On 2016-12-06 14:19:21 -0600, Nico Williams wrote:
> I concur with your feeling that hand-rolled JIT is right out. But
Ye
On Tue, Dec 6, 2016 at 11:10:59AM -0800, Andres Freund wrote:
> > I concur with your feeling that hand-rolled JIT is right out. But
> > I'm not sure that whatever performance gain we might get in this
> > direction is worth the costs.
>
> Well, I'm not impartial, but I don't think we do our user
On Mon, Dec 12, 2016 at 6:14 PM, Andres Freund wrote:
>
>
> For Q1 I think the bigger win is JITing the transition function
> invocation in advance_aggregates/transition_function - that's IIRC where
> the biggest bottleneck lies.
>
Yeah, we bundle the agg core into our expr work... no point other
Hi,
On 2016-12-12 18:11:13 -0800, CK Tan wrote:
> Andres,
> > dev (no jiting):
> > Time: 30343.532 ms
>
> > dev (jiting):
> > SET jit_tuple_deforming = on;
> > SET jit_expressions = true;
> >
> > Time: 24439.803 ms
>
> FYI, ~20% improvement for TPCH Q1 is consistent with what we find when we
>
Andres,
> dev (no jiting):
> Time: 30343.532 ms
> dev (jiting):
> SET jit_tuple_deforming = on;
> SET jit_expressions = true;
>
> Time: 24439.803 ms
FYI, ~20% improvement for TPCH Q1 is consistent with what we find when we
only jit expression.
Cheers,
-cktan
On Tue, Dec 6, 2016 at 9:19 AM, Andres Freund wrote:
> 0009 WIP: Add minimal keytest implementation.
>
> More or less experimental patch that tries to implement simple
> expression of the OpExpr(ScalarVar, Const) into a single expression
> evaluation step. The benefits probably aren't big enough
On 7 December 2016 at 14:39, Craig Ringer wrote:
> On 7 December 2016 at 04:13, Robert Haas wrote:
>
>> I wonder how feasible it would be to make this a run-time dependency
>> rather than a compile option.
>
> Or something that's compiled with the server, but produces a separate
> .so that's the
On 7 December 2016 at 04:13, Robert Haas wrote:
> I wonder how feasible it would be to make this a run-time dependency
> rather than a compile option.
Or something that's compiled with the server, but produces a separate
.so that's the only thing that links to LLVM. So packagers can avoid a
depe
On 2016-12-06 13:27:14 -0800, Peter Geoghegan wrote:
> On Mon, Dec 5, 2016 at 7:49 PM, Andres Freund wrote:
> > I tried to address 2) by changing the C implementation. That brings some
> > measurable speedups, but it's not huge. A bigger speedup is making
> > slot_getattr, slot_getsomeattrs, slot_
On Mon, Dec 5, 2016 at 7:49 PM, Andres Freund wrote:
> I tried to address 2) by changing the C implementation. That brings some
> measurable speedups, but it's not huge. A bigger speedup is making
> slot_getattr, slot_getsomeattrs, slot_getallattrs very trivial wrappers;
> but it's still not huge.
On Tue, Dec 06, 2016 at 12:36:41PM -0800, Andres Freund wrote:
> On 2016-12-06 15:25:44 -0500, Tom Lane wrote:
> > I'm not entirely thrilled with the idea of this being a configure-time
> > decision, because that forces packagers to decide for their entire
> > audience whether it's okay to depend o
On 2016-12-06 14:35:43 -0600, Nico Williams wrote:
> On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote:
> > On 2016-12-06 14:19:21 -0600, Nico Williams wrote:
> > > > I concur with your feeling that hand-rolled JIT is right out. But
> > >
> > > Yeah, that way lies maintenance madness.
On 2016-12-06 15:25:44 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-12-06 13:56:28 -0500, Tom Lane wrote:
> >> I guess the $64 question that has to be addressed here is whether we're
> >> prepared to accept LLVM as a run-time dependency. There are some reasons
> >> why we might not
On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote:
> On 2016-12-06 14:19:21 -0600, Nico Williams wrote:
> > A bigger concern might be interface stability. IIRC the LLVM C/C++
> > interfaces are not very stable, but bitcode is.
>
> The C API is a lot more stable than the C++ bit, that'
Hi,
On 2016-12-06 14:19:21 -0600, Nico Williams wrote:
> A bigger concern might be interface stability. IIRC the LLVM C/C++
> interfaces are not very stable, but bitcode is.
The C API is a lot more stable than the C++ bit, that's the primary
reason I ended up using it, despite the C++ docs being
Andres Freund writes:
> On 2016-12-06 13:56:28 -0500, Tom Lane wrote:
>> I guess the $64 question that has to be addressed here is whether we're
>> prepared to accept LLVM as a run-time dependency. There are some reasons
>> why we might not be:
> Indeed. It'd only be a soft dependency obviously
On Tue, Dec 06, 2016 at 01:56:28PM -0500, Tom Lane wrote:
> Andres Freund writes:
> > I'm posting a quite massive series of WIP patches here, to get some
> > feedback.
>
> I guess the $64 question that has to be addressed here is whether we're
> prepared to accept LLVM as a run-time dependency.
On 2016-12-06 15:13:21 -0500, Robert Haas wrote:
> Presumably this is going to need to be something that a user can get
> via yum install or apt-get install on common systems.
Right. apt-get install llvm-dev (or llvm-3.9-dev or such if you want to
install a specific version), does the trick here
On Tue, Dec 6, 2016 at 2:10 PM, Andres Freund wrote:
>> * The sheer mass of the dependency. What's the installed footprint of
>> LLVM, versus a Postgres server? How hard is it to install from source?
>
> Worked for me first try, but I'm perhaps not the best person to judge.
> It does take a whil
On 2016-12-06 11:10:59 -0800, Andres Freund wrote:
> > * Are there any currently-interesting platforms that LLVM doesn't work
> > for? (I'm worried about RISC-V as much as legacy systems.)
>
> LLVM itself I don't think is a problem, it seems to target a wide range
> of platforms. The platforms th
On 2016-12-06 14:04:09 -0500, Robert Haas wrote:
> I've heard at least one and maybe several PGCon presentations about
> people JITing tuple deformation and getting big speedups, and I'd like
> to finally hear one from somebody who intends to integrate that into
> PostgreSQL.
I certainly want to.
Hi,
On 2016-12-06 13:56:28 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I'm posting a quite massive series of WIP patches here, to get some
> > feedback.
>
> I guess the $64 question that has to be addressed here is whether we're
> prepared to accept LLVM as a run-time dependency. There
On Tue, Dec 6, 2016 at 1:56 PM, Tom Lane wrote:
> Andres Freund writes:
>> I'm posting a quite massive series of WIP patches here, to get some
>> feedback.
>
> I guess the $64 question that has to be addressed here is whether we're
> prepared to accept LLVM as a run-time dependency. There are so
Andres Freund writes:
> I'm posting a quite massive series of WIP patches here, to get some
> feedback.
I guess the $64 question that has to be addressed here is whether we're
prepared to accept LLVM as a run-time dependency. There are some reasons
why we might not be:
* The sheer mass of the d
25 matches
Mail list logo