On Mon, Feb 1, 2016 at 10:35 PM, Daniel Rogers wrote:
>>> * Anyone can do dynamic compilation nowadays with llvm. Imagine
>>>
>>> taking the gegl dynamic tree, and compiling it into a single LLVM
>>> dynamically compiled function.
>>
>> What exactly do you
Hi Daniel,
thanks for sharing your thoughts. I agree with you in many points.
On 29.1.2016 at 5:37 PM Daniel Rogers wrote:
* Anyone can do dynamic compilation nowadays with llvm. Imagine
taking the gegl dynamic tree, and compiling it into a single LLVM
dynamically compiled
On Feb 1, 2016 12:40 PM, "Sven Claussner" wrote:
> On 29.1.2016 at 5:37 PM Daniel Rogers wrote:
>>
>> * Anyone can do dynamic compilation nowadays with llvm. Imagine
>>
>> taking the gegl dynamic tree, and compiling it into a single LLVM
>> dynamically compiled
On Fri, Jan 29, 2016 at 5:41 AM, Sven Claussner wrote:
> On 28.1.2016 at 10:29 PM Daniel Rogers wrote:
>> I am confused. What technical reason exists to assume gegl cannot be as
>> fast as vips? Is it memory usage? Extra necessary calculations? Some way
>> in which
On Jan 29, 2016 6:20 AM, "Øyvind Kolås" wrote:
>
> GEGL is doing single precision 32bit floating point processing for all
> operations, thus should not introduce the type of quantization
> problems 8bpc/16bpc pipelines introduce for multiple filters - at the
> expense of much
Hello all, vips maintainer here, thank you for this interesting discussion.
On 29 January 2016 at 16:37, Daniel Rogers wrote:
> A fast 8 bit pipeline is great for previews or single operation stacks, or
> when accuracy is not as important for the user.
My feeling is
As someone new to the gegl development list and seeing the performance
numbers in that benchmark, I propose adding a asterisk * by each gegl
number would help the reader understand that something is different with
this library. Then add the corresponding asterisk down by the statement, "GEGL
is
Hi Sven,
I am confused. What technical reason exists to assume gegl cannot be as
fast as vips? Is it memory usage? Extra necessary calculations? Some way in
which parallelism is not as possible?
--
Daniel
On Jan 28, 2016 12:58 PM, "Sven Claussner" wrote:
> Hi,
>
> the
On 28.1.2016 at 10:29 PM Daniel Rogers wrote:
> Hi Sven,
>
> I am confused. What technical reason exists to assume gegl cannot be as
> fast as vips? Is it memory usage? Extra necessary calculations? Some way
> in which parallelism is not as possible?
Hi Daniel,
you might have misunderstood