Re: non empty slices
On Thursday, 2 June 2016 at 23:44:49 UTC, ag0aep6g wrote: On 06/03/2016 01:35 AM, ag0aep6g wrote: The alternative `peek` method is not documented to throw an exception, but it's not @nogc either. No idea why. Maybe Algebraic does GC allocations internally. I wouldn't know for what, though. Or it misses a @nogc somewhere. I've looked at the source to see if it's something simple, and Algebraic/VariantN seems to be terribly complicated. Writing a simpler @nogc tagged union may be easier than fixing the phobos one, if the phobos one can even be made @nogc. I'm also inside the source... yes, its not a simple one. I think I will try to write my own one...
Re: non empty slices
On Thursday, 2 June 2016 at 23:35:53 UTC, ag0aep6g wrote: It's the Algebraic. The `get` method isn't @nogc. The documentation [1] says that it may throw an exception, which is most probably being allocated through the GC. So that's a reason why it can't be @nogc. The alternative `peek` method is not documented to throw an exception, but it's not @nogc either. No idea why. Maybe Algebraic does GC allocations internally. I wouldn't know for what, though. Or it misses a @nogc somewhere. [1] http://dlang.org/phobos/std_variant#.VariantN.get Yeah... thanks a lot!
Re: non empty slices
On 06/03/2016 01:35 AM, ag0aep6g wrote: The alternative `peek` method is not documented to throw an exception, but it's not @nogc either. No idea why. Maybe Algebraic does GC allocations internally. I wouldn't know for what, though. Or it misses a @nogc somewhere. I've looked at the source to see if it's something simple, and Algebraic/VariantN seems to be terribly complicated. Writing a simpler @nogc tagged union may be easier than fixing the phobos one, if the phobos one can even be made @nogc.
Re: non empty slices
On 06/03/2016 01:17 AM, Alex wrote: But still, I can't mark the f-method @nogc, and this is not due to the writeln calls... why GC is invoked, although everything is known and no memory allocation should happen? It's the Algebraic. The `get` method isn't @nogc. The documentation [1] says that it may throw an exception, which is most probably being allocated through the GC. So that's a reason why it can't be @nogc. The alternative `peek` method is not documented to throw an exception, but it's not @nogc either. No idea why. Maybe Algebraic does GC allocations internally. I wouldn't know for what, though. Or it misses a @nogc somewhere. [1] http://dlang.org/phobos/std_variant#.VariantN.get
Re: Creating a "fixed-range int" with opDispatch and/or alias this?
On Wednesday, 1 June 2016 at 19:59:51 UTC, Mark Isaacson wrote: I'm trying to create a type that for all intents and purposes behaves exactly like an int except that it limits its values to be within a certain range [a,b]. Theoretically, I would think this looks something like: ... It looks like opDispatch doesn't participate in resolution of operator overloads. Is there any way I can achieve my desired result? I know alias this forwards operations like +=, but with alias this I cannot wrap the operation to do the bounds checking. I think you would need to implement all of: * this(...) * opAssign(...) * opOpAssign(...) * opBinary(...) * opBinaryRight(...) * opUnary(...) FWIW, the fixed range int part of this question is just an example, I'm mostly just interested in whether this idea is possible without a lot of bloat/duplication. For a single type, I think the bloat is required. If you want to generate a lot of similar types, though, you could probably write a mixin template to generate the methods for you.
Re: non empty slices
On Thursday, 2 June 2016 at 22:17:32 UTC, ag0aep6g wrote:
Yeah, can't do it that way. You have only one f_impl call, but
want it to go to different overloads based on dynamic
information (caseS). That doesn't work.
You need three different f_impl calls. You can generate them,
so there's only one in the source, but it's a bit involved:
sw: switch (caseS)
{
foreach (i, T; TL)
{
case i: f_impl(result.get!T); break sw;
}
default: assert(false);
}
Oh... wow... cool! :)
But still, I can't mark the f-method @nogc, and this is not due
to the writeln calls... why GC is invoked, although everything is
known and no memory allocation should happen?
Re: non empty slices
On 06/02/2016 11:37 PM, Alex wrote:
Just tried this instead of your f-function:
void f(int[] arr)
{
A result;
import std.meta;
alias TL = AliasSeq!(Empty, int, Many!int);
int caseS;
switch (arr.length)
{
case 0: result = Empty.init; caseS = 0; break;
case 1: result = arr[0]; caseS = 1; break;
default: result = Many!int(arr); caseS = 2;
}
f_impl(*result.get!(TL[caseS]));
}
But got: Error: variable caseS cannot be read at compile time
which is obviously true...
Yeah, can't do it that way. You have only one f_impl call, but want it
to go to different overloads based on dynamic information (caseS). That
doesn't work.
You need three different f_impl calls. You can generate them, so there's
only one in the source, but it's a bit involved:
sw: switch (caseS)
{
foreach (i, T; TL)
{
case i: f_impl(result.get!T); break sw;
}
default: assert(false);
}
Re: non empty slices
On 06/02/2016 10:11 PM, Alex wrote: The cool thing about the Algebraic is as I expected, that it doesn't change it's type... And the hard thing is, that I'm not used to its Empty, Many, ... things yet. I just made those up on the spot. Note that Many is not actually implemented at all. There is no check that the array has at least two elements. And Empty is just there, because I needed a type for the Algebraic. But the question remains how to keep this @nogc? Apparently, it's Algebraic that isn't @nogc. I don't know what it allocates. Maybe it allocates space for large types (but there aren't any here), or maybe it can throw a GC-allocated exception. I wonder at the line with peek... and why it is not just returning the value... I wouldn't expect that to be the problem with @nogc. As far as I see, the pointer is used as a way to return "not found" in the form of null. When you get a non-null pointer it's probably just into the Algebraic.
Re: non empty slices
On Thursday, 2 June 2016 at 20:11:21 UTC, Alex wrote:
On Thursday, 2 June 2016 at 16:21:03 UTC, ag0aep6g wrote:
void f(int[] arr)
{
A a = arrayToA(arr);
foreach (T; A.AllowedTypes)
{
if (T* p = a.peek!T) f_impl(*p);
}
}
You totally hit the point!
The cool thing about the Algebraic is as I expected, that it
doesn't change it's type... And the hard thing is, that I'm not
used to its Empty, Many, ... things yet.
But the question remains how to keep this @nogc? I wonder at
the line with peek... and why it is not just returning the
value...
Just tried this instead of your f-function:
void f(int[] arr)
{
A result;
import std.meta;
alias TL = AliasSeq!(Empty, int, Many!int);
int caseS;
switch (arr.length)
{
case 0: result = Empty.init; caseS = 0; break;
case 1: result = arr[0]; caseS = 1; break;
default: result = Many!int(arr); caseS = 2;
}
f_impl(*result.get!(TL[caseS]));
}
But got: Error: variable caseS cannot be read at compile time
which is obviously true...
Re: Speed up `dub`.
On 2016-06-02 15:07, ciechowoj wrote: Maybe it would be worth to write something about the issue here https://github.com/dlang/dub#installation . I'm curious how the pre-compiled versions are built. Yeah, I really hope they're built with optimizations enabled. -- /Jacob Carlborg
Re: non empty slices
On Thursday, 2 June 2016 at 16:21:03 UTC, ag0aep6g wrote:
On 06/02/2016 05:16 PM, Alex wrote:
I may be getting what you're up to. Maybe not.
So we start with something like this (using arrays instead of
arbitrary ranges to keep things simple):
import std.stdio: writeln;
void main()
{
f([]);
f([1]);
f([1, 2]);
}
void f(int[] a)
{
if (a.length == 0) f_none(a);
else if (a.length == 1) f_one(a);
else f_many(a);
}
void f_none(int[] a)
{
writeln("nothing to see here");
}
void f_one(int[] a)
{
assert(a.length == 1);
writeln("exactly one: ", a[0]);
}
void f_many(int[] a)
{
assert(a.length >= 2);
writeln("at least two: ", a[0 .. 2]);
}
And instead you'd like something more like this:
import std.stdio: writeln;
import std.variant: Algebraic;
void main()
{
f([]);
f([1]);
f([1, 2]);
}
void f(int[] arr)
{
A a = arrayToA(arr);
foreach (T; A.AllowedTypes)
{
if (T* p = a.peek!T) f_impl(*p);
}
}
void f_impl(Empty e) { writeln("nothing to see here"); }
void f_impl(int a) { writeln("exactly one: ", a); }
void f_impl(Many!int a) { writeln("at least two: ", a[0 ..
2]); }
struct Empty {}
struct Many(T)
{
T[] arr;
alias arr this;
/* Somehow it's enforced here that arr.length >= 2. */
}
alias A = Algebraic!(Empty, int, Many!int);
A arrayToA(int[] a)
{
A result;
switch (a.length)
{
case 0: result = Empty.init; break;
case 1: result = a[0]; break;
default: result = Many!int(a);
}
return result;
}
And the advantages of it are:
* Don't need asserts in the different `f_impl`s.
Yes.
* The branching in f is guided by the parameter types of f_impl
(could possibly be extracted, instead of being hardcoded
manually).
Yes! :)
Tell me if I'm way off.
You totally hit the point!
The cool thing about the Algebraic is as I expected, that it
doesn't change it's type... And the hard thing is, that I'm not
used to its Empty, Many, ... things yet.
But the question remains how to keep this @nogc? I wonder at the
line with peek... and why it is not just returning the value...
Re: Derive interface from class?
You can see how AutoImplement works for example https://github.com/dlang/phobos/blob/master/std/typecons.d#L3269
Re: Derive interface from class?
On Thursday, 2 June 2016 at 16:14:47 UTC, Pie? wrote:
Since D uses the single inheritance model for classes, I wonder
if it is possible to write a class then extract the interface
from it?
e.g.,
class myclass
{
public void foo() { writeln("adf"); }
}
mixin!(extractInterface!(myclass, myinterface));
Where the mixin creates the interface as if I typed it by hand:
interface myinterface
{
void foo();
}
This would greatly simplify having to start writing from a base
interface then add the class. It would also let one do multiple
inheritance from classes that are already defined.
Since every class must have a well defined interface, this
seems like it should be possible and relatively easy using
reflection. A bad idea?
I guess the main issue here is that myclass would then need to be
specified as being derived from myinterface after it was
generated! Not sure if this is possible to solve in D?
Re: Can I get a more in-depth guide about the inline assembler?
On Thursday, 2 June 2016 at 13:32:51 UTC, ZILtoid1991 wrote:
On Thursday, 2 June 2016 at 07:17:23 UTC, Johan Engelen wrote:
Could you also paste the D version of your code? Perhaps the
compiler (LDC, GDC) will generate similarly vectorized code
that is inlinable, etc.
ubyte[4] dest2 = *p;
dest2[1] = to!ubyte((src[1] * (src[0] + 1) + dest2[1] * (256 -
src[0]))>>8);
dest2[2] = to!ubyte((src[2] * (src[0] + 1) + dest2[2] * (256 -
src[0]))>>8);
dest2[3] = to!ubyte((src[3] * (src[0] + 1) + dest2[3] * (256 -
src[0]))>>8);
*p = dest2;
The main problem with this is that it's much slower, even if I
would calculate the alpha blending values once. The assembly
code does not seem to have higher impact than the "replace if
alpha = 255" algorithm:
if(src[0] == 255){
*p = src;
}
It also seems I have a quite few problems with the assembly
code, mostly with the pmulhuw command (it returns the higher 16
bit of the result, I need the lower 16 bit as unsigned), also
with the pointers, as the read outs and write backs doesn't
land to their correct places, sometimes resulting in a
flickering screen or wrong colors affecting neighboring pixels.
Current assembly code:
I'd say the major portion of your speedup happens to be because
you're trying to do 3 things at once. Rather specifically,
because you're working with 3 8bit colors, you have 24bits of
data to work with, and by adding 8bits for fixed floating point
you can do a multiply and do 4 small multiplies in a single
command.
You'd probably get a similar effect from bit shifting before and
after the results. Since you're working with 3 colors and the
alpha/multiplier... This assumes you do it without MMX. (reduces
6 multiplies to a mere 2)
ulong tmp1 = (src[1] << 32) | (src[2] << 16) | src[3];
ulong tmp2 = (dest2[1] << 32) | (dest2[2] << 16) | dest2[3];
tmp1 *= src[0]+1;
tmp1 += tmp2*(256 - src[0]);
src[3] = (tmp1 >> 8) & 0xff;
src[2] = (tmp1 >> 24) & 0xff;
src[1] = (tmp1 >> 40) & 0xff;
You could also increase the bit precision up so if you decided
to do further adds or some other calculations it would have more
room to fudge with, but not much. Say if you gave yourself 20
bits per variable rather than 16, the values can then hold 16x
higher for getting say the average of x values at no cost (if
divisible by ^2) other than a little difference in how you write
it :)
Although you might still get a better result from MMX
instructions if you have them in the right order. Don't forget
though MMX uses the same register space as floating point, so
mixing the two is a big no-no.
Re: non empty slices
On 06/02/2016 05:16 PM, Alex wrote:
What I mean is: if there would be a possibility to use algebraic types
here (or maybe some kind of template...), then my types would be able
(maybe! did not seen anything similar yet...) to choose the proper
methods for themselves automatically:
As long as my type has a length > 1 it is handled as a range, if the
range has the length=1 it is handled as a single element and not as a
range, if the range has the length=0 it is handled as an absent element.
I may be getting what you're up to. Maybe not.
So we start with something like this (using arrays instead of arbitrary
ranges to keep things simple):
import std.stdio: writeln;
void main()
{
f([]);
f([1]);
f([1, 2]);
}
void f(int[] a)
{
if (a.length == 0) f_none(a);
else if (a.length == 1) f_one(a);
else f_many(a);
}
void f_none(int[] a)
{
writeln("nothing to see here");
}
void f_one(int[] a)
{
assert(a.length == 1);
writeln("exactly one: ", a[0]);
}
void f_many(int[] a)
{
assert(a.length >= 2);
writeln("at least two: ", a[0 .. 2]);
}
And instead you'd like something more like this:
import std.stdio: writeln;
import std.variant: Algebraic;
void main()
{
f([]);
f([1]);
f([1, 2]);
}
void f(int[] arr)
{
A a = arrayToA(arr);
foreach (T; A.AllowedTypes)
{
if (T* p = a.peek!T) f_impl(*p);
}
}
void f_impl(Empty e) { writeln("nothing to see here"); }
void f_impl(int a) { writeln("exactly one: ", a); }
void f_impl(Many!int a) { writeln("at least two: ", a[0 .. 2]); }
struct Empty {}
struct Many(T)
{
T[] arr;
alias arr this;
/* Somehow it's enforced here that arr.length >= 2. */
}
alias A = Algebraic!(Empty, int, Many!int);
A arrayToA(int[] a)
{
A result;
switch (a.length)
{
case 0: result = Empty.init; break;
case 1: result = a[0]; break;
default: result = Many!int(a);
}
return result;
}
And the advantages of it are:
* Don't need asserts in the different `f_impl`s.
* The branching in f is guided by the parameter types of f_impl (could
possibly be extracted, instead of being hardcoded manually).
Tell me if I'm way off.
Derive interface from class?
Since D uses the single inheritance model for classes, I wonder
if it is possible to write a class then extract the interface
from it?
e.g.,
class myclass
{
public void foo() { writeln("adf"); }
}
mixin!(extractInterface!(myclass, myinterface));
Where the mixin creates the interface as if I typed it by hand:
interface myinterface
{
void foo();
}
This would greatly simplify having to start writing from a base
interface then add the class. It would also let one do multiple
inheritance from classes that are already defined.
Since every class must have a well defined interface, this seems
like it should be possible and relatively easy using reflection.
A bad idea?
Re: Asio Bindings?
On Thursday, 2 June 2016 at 11:15:59 UTC, Guillaume Piolat wrote: On Thursday, 2 June 2016 at 06:28:51 UTC, Pie? wrote: On Thursday, 2 June 2016 at 04:52:50 UTC, Mithun Hunsur wrote: On Thursday, 2 June 2016 at 04:02:36 UTC, Pie? wrote: Does anyone know if there is any Asio bindings or direct D available that allows for IO? Check out vibe.d: https://vibed.org/ - it includes a fairly complete implementation of asynchronous I/O, among other things. Oh, lol, I should have mentioned I meant for audio! ;) It doesn't seem to exist but using bindings for FMOD you should be able to access ASIO as an audio driver. If FMOD is that commercial sound lib then I'm not interested. I guess I'll have to try and write some type of asio lib when I get around to it. Hopefully it is not too difficult.
Re: non empty slices
On Thursday, 2 June 2016 at 14:31:15 UTC, ag0aep6g wrote: A little terminology: "Slice" is not a synonym for "range". iota does not return a slice, it returns a range. "Slice" is being used as a synonym for "dynamic array" (Type[]), and in the context of the slicing operator (expression[] or expression[a .. b]). Now, for the actual question - how to define a range that is non-empty by definition: One of the range primitives is popFront. popFront removes one element from the range. popFront cannot change the type of the range. So you can't have a type that is a range, and is guaranteed not to be empty, and can be emptied by calling popFront. But you can have a type that is a range, is guaranteed not to be empty, and *cannot* be emptied by calling popFront: an infinite range. That's a range that never gets empty no matter how often popFront is called. The library recognizes infinite ranges when you define `empty` like this: `enum bool empty = false;`. There's std.range.primitives.isInfinite [1] to check for them. I guess that's not really what you're looking for. Yes, that's not. :) I don't think you can otherwise statically check that a range isn't empty. You could probably make a wrapper that checks once on construction, but that's still a run-time check. And I don't see it being particularly useful, because popFront is an essential parts of ranges. So this would mean, the contract I use now for run-time check is ok. And... well... maybe I can alias two different methods, one which returns an arbitrary range and one which returns a range, checked for emptiness in an out contract... This already would save a lot of code duplication... You've lost me there. I don't see how non-empty range and Algebraic connect. What I mean is: if there would be a possibility to use algebraic types here (or maybe some kind of template...), then my types would be able (maybe! did not seen anything similar yet...) to choose the proper methods for themselves automatically: As long as my type has a length > 1 it is handled as a range, if the range has the length=1 it is handled as a single element and not as a range, if the range has the length=0 it is handled as an absent element.
Re: Creating a "fixed-range int" with opDispatch and/or alias this?
On 06/02/2016 07:59 AM, Ali Çehreli wrote:
> On 06/01/2016 12:59 PM, Mark Isaacson wrote:
>> I'm trying to create a type that for all intents and purposes behaves
>> exactly like an int except that it limits its values to be within a
>> certain range [a,b].
>
> 'alias this' with property functions work at least for your example:
I can't believe I wrote that. :) No, it doesn't work.
> struct FixedRangeInt {
> int min;
> int max;
> int i_;
>
> int value() const {
> return i_;
> }
>
> void value(int i) {
> assert(i >= min);
> assert(i < max);
And those better be moved to an invariant block. However, 'alias value
this' does not work and 'alias i_ this' has no effect because there is
no member-function called, so the invariant block is not executed.
> i_ = i;
> }
>
> alias i_ this;
Silly mistake up there. :-/
> }
>
> void main() {
> auto f = FixedRangeInt(0, 100);
> f += 2;
> assert(f == 2);
> }
>
> Ali
>
Sorry for the noise.
Ali
Re: Creating a "fixed-range int" with opDispatch and/or alias this?
On 06/02/2016 04:59 PM, Ali Çehreli wrote:
'alias this' with property functions work at least for your example:
struct FixedRangeInt {
int min;
int max;
int i_;
int value() const {
return i_;
}
void value(int i) {
assert(i >= min);
assert(i < max);
i_ = i;
}
alias i_ this;
}
void main() {
auto f = FixedRangeInt(0, 100);
f += 2;
assert(f == 2);
}
Ali
The `value` methods are never called here. The checks are not performed.
Re: Creating a "fixed-range int" with opDispatch and/or alias this?
On 06/01/2016 12:59 PM, Mark Isaacson wrote:
I'm trying to create a type that for all intents and purposes behaves
exactly like an int except that it limits its values to be within a
certain range [a,b].
'alias this' with property functions work at least for your example:
struct FixedRangeInt {
int min;
int max;
int i_;
int value() const {
return i_;
}
void value(int i) {
assert(i >= min);
assert(i < max);
i_ = i;
}
alias i_ this;
}
void main() {
auto f = FixedRangeInt(0, 100);
f += 2;
assert(f == 2);
}
Ali
Re: non empty slices
On 06/02/2016 03:37 PM, Alex wrote: The question is, how to define the same thing for ranges. What I started with is: import std.range : iota; alias MrSlice = typeof(iota(M.init)); so far, so good. The MrSlice-thing is the analogy for Mr, as it can be empty, as Mr can. What I also need is the analogy for the M-thing. But how can I define a slice, which is not-empty by definition? A little terminology: "Slice" is not a synonym for "range". iota does not return a slice, it returns a range. "Slice" is being used as a synonym for "dynamic array" (Type[]), and in the context of the slicing operator (expression[] or expression[a .. b]). Now, for the actual question - how to define a range that is non-empty by definition: One of the range primitives is popFront. popFront removes one element from the range. popFront cannot change the type of the range. So you can't have a type that is a range, and is guaranteed not to be empty, and can be emptied by calling popFront. But you can have a type that is a range, is guaranteed not to be empty, and *cannot* be emptied by calling popFront: an infinite range. That's a range that never gets empty no matter how often popFront is called. The library recognizes infinite ranges when you define `empty` like this: `enum bool empty = false;`. There's std.range.primitives.isInfinite [1] to check for them. I guess that's not really what you're looking for. I don't think you can otherwise statically check that a range isn't empty. You could probably make a wrapper that checks once on construction, but that's still a run-time check. And I don't see it being particularly useful, because popFront is an essential parts of ranges. [...] I tried also something using Algebraic types with an underlying int, but couldn't manage to append elements to something like: alias List2 = Algebraic!(This[]); or alias List(Leaf) = Algebraic!(Leaf, This*); The cool thing is, if the algebraic stuff works, it would potentially be able to replace all four aliases altogether... But a knock-out criteria is: the solution has to be @nogc You've lost me there. I don't see how non-empty range and Algebraic connect. [1] https://dlang.org/phobos/std_range_primitives.html#.isInfinite
non empty slices
Ok, a strange question from my side again...
Let's begin, with what works:
Say, I define two types:
import std.typecons : Nullable;
alias M = uint;
alias Mr = Nullable!M;
then, I can write two types of methods. Those which can handle
Mr's:
void fun1(Mr val)
{
//do some funny stuff
}
and those, which assume an existing value is provided:
void fun2(M val)
{
//do some other funny stuff
}
they could be overloaded by using the same name I think... but
this is not the point.
The question is, how to define the same thing for ranges. What I
started with is:
import std.range : iota;
alias MrSlice = typeof(iota(M.init));
so far, so good. The MrSlice-thing is the analogy for Mr, as it
can be empty, as Mr can.
What I also need is the analogy for the M-thing. But how can I
define a slice, which is not-empty by definition?
A workaround, which works is for example, using in a function
which assumes a non-empty slice a contract:
void fun3(MrSlice val)
in
{
assert(!val.empty);
}
body
{
// do some funny stuff, part 3 :)
}
I tried also something using Algebraic types with an underlying
int, but couldn't manage to append elements to something like:
alias List2 = Algebraic!(This[]);
or
alias List(Leaf) = Algebraic!(Leaf, This*);
The cool thing is, if the algebraic stuff works, it would
potentially be able to replace all four aliases altogether...
But a knock-out criteria is: the solution has to be @nogc
Re: Can I get a more in-depth guide about the inline assembler?
On Thursday, 2 June 2016 at 07:17:23 UTC, Johan Engelen wrote:
On Wednesday, 1 June 2016 at 23:23:49 UTC, ZILtoid1991 wrote:
Here's the assembly code for my alpha-blending routine:
Could you also paste the D version of your code? Perhaps the
compiler (LDC, GDC) will generate similarly vectorized code
that is inlinable, etc.
-Johan
ubyte[4] dest2 = *p;
dest2[1] = to!ubyte((src[1] * (src[0] + 1) + dest2[1] * (256 -
src[0]))>>8);
dest2[2] = to!ubyte((src[2] * (src[0] + 1) + dest2[2] * (256 -
src[0]))>>8);
dest2[3] = to!ubyte((src[3] * (src[0] + 1) + dest2[3] * (256 -
src[0]))>>8);
*p = dest2;
The main problem with this is that it's much slower, even if I
would calculate the alpha blending values once. The assembly code
does not seem to have higher impact than the "replace if alpha =
255" algorithm:
if(src[0] == 255){
*p = src;
}
It also seems I have a quite few problems with the assembly code,
mostly with the pmulhuw command (it returns the higher 16 bit of
the result, I need the lower 16 bit as unsigned), also with the
pointers, as the read outs and write backs doesn't land to their
correct places, sometimes resulting in a flickering screen or
wrong colors affecting neighboring pixels. Current assembly code:
//ushort[4] alpha = [src[0],src[0],src[0],src[0]]; //replace it
if there's a faster method for this
ushort[4] alpha = [100,100,100,100];
//src[3] = 255;
ubyte[4] *p2 = cast(ubyte[4]*)src2.ptr;
ushort[4] *p3 = cast(ushort[4]*)alpha.ptr;
ushort[4] *pc_1 = cast(ushort[4]*)alphaMMXmul_const1.ptr;
ushort[4] *pc_256 = cast(ushort[4]*)alphaMMXmul_const256.ptr;
asm{
//moving the values to their destinations
mov
ESI, p2[EBP];
mov EDI, p[EBP];
movdMM0, [ESI];
movdMM1, [EDI];
mov ESI, p3[EBP];
movqMM5, [ESI];
mov ESI, pc_256[EBP];
movqMM7, [ESI];
mov ESI, pc_1[EBP];
movqMM6, [ESI];
punpcklbw MM2, MM0;
punpcklbw MM3, MM1;
paddw MM6, MM5; //1 + alpha
psubw MM7, MM5; //256 - alpha
//psllw MM2, 2;
//psllw MM3, 2;
psrlw MM6, 1;
psrlw MM7, 1;
pmullw MM2, MM6; //src * (1 + alpha)
pmullw MM3, MM7; //dest * (256 - alpha)
paddw MM3, MM2; //(src * (1 + alpha)) + (dest * (256 - alpha))
psrlw MM3, 8; //(src * (1 + alpha)) + (dest * (256 - alpha)) /
256
//moving the result to its place;
packuswbMM4, MM3;
movd[EDI-3], MM4;
emms;
}
Tried to get the correct result with trial and error, but there's
no real improvement.
Re: Speed up `dub`.
I am not sure but on Arch linux I always recompile dub myself because by default it is build without release flags too. Dne 2.6.2016 v 15:07 ciechowoj via Digitalmars-d-learn napsal(a): Maybe it would be worth to write something about the issue here https://github.com/dlang/dub#installation . I'm curious how the pre-compiled versions are built.
Re: Speed up `dub`.
Maybe it would be worth to write something about the issue here https://github.com/dlang/dub#installation . I'm curious how the pre-compiled versions are built.
Re: Speed up `dub`.
On Thursday, 2 June 2016 at 12:20:50 UTC, Jacob Carlborg wrote:
On 2016-06-01 23:33, ciechowoj wrote:
Hahahaa. Who could possibly think that `build.sh` builds dub
in debug
mode? With -release -O -inline -m64 it runs 5 times faster :
P. It made
my day...
Haha really?
Yes, I should have done it at the beginning, but yesterday I
decided to see what is really happening and compiled dub with
`-profile` and found that an assert from `std/path.d:3168`
(`globMatch`) contributes a major amount to the running time of
dub.
```
assert(balancedParens(pattern, '[', ']', 0));
assert(balancedParens(pattern, '{', '}', 0));
```
Re: Speed up `dub`.
On 2016-06-01 23:33, ciechowoj wrote: Hahahaa. Who could possibly think that `build.sh` builds dub in debug mode? With -release -O -inline -m64 it runs 5 times faster : P. It made my day... Haha really? -- /Jacob Carlborg
Re: opCall override default constructor?
On 2016-06-02 12:16, Marc Schütz wrote: It's this bug: https://issues.dlang.org/show_bug.cgi?id=9078 Ok, thanks. -- /Jacob Carlborg
Re: Asio Bindings?
On Thursday, 2 June 2016 at 06:28:51 UTC, Pie? wrote: On Thursday, 2 June 2016 at 04:52:50 UTC, Mithun Hunsur wrote: On Thursday, 2 June 2016 at 04:02:36 UTC, Pie? wrote: Does anyone know if there is any Asio bindings or direct D available that allows for IO? Check out vibe.d: https://vibed.org/ - it includes a fairly complete implementation of asynchronous I/O, among other things. Oh, lol, I should have mentioned I meant for audio! ;) It doesn't seem to exist but using bindings for FMOD you should be able to access ASIO as an audio driver.
Re: opCall override default constructor?
On Thursday, 2 June 2016 at 08:50:26 UTC, Jacob Carlborg wrote:
Is it intentional that a non-static opCall overrides the
default constructor of a struct?
struct Foo
{
int a;
void opCall(string b) { }
}
void main()
{
auto f = Foo(3); // line 14
f("asd");
}
The above code gives the following error:
main.d(14): Error: function main.Foo.opCall (string b) is not
callable using argument types (int)
It's this bug:
https://issues.dlang.org/show_bug.cgi?id=9078
Re: opCall override default constructor?
On Thursday, 2 June 2016 at 08:50:26 UTC, Jacob Carlborg wrote: Is it intentional that a non-static opCall overrides the default constructor of a struct? auto f = Foo(3); // line 14 main.d(14): Error: function main.Foo.opCall (string b) is not callable using argument types (int) It sounds like a bug, since the object isn't instantiated yet it shouldn't be able to call opCall yet...
opCall override default constructor?
Is it intentional that a non-static opCall overrides the default
constructor of a struct?
struct Foo
{
int a;
void opCall(string b) { }
}
void main()
{
auto f = Foo(3); // line 14
f("asd");
}
The above code gives the following error:
main.d(14): Error: function main.Foo.opCall (string b) is not callable
using argument types (int)
--
/Jacob Carlborg
Re: Can I get a more in-depth guide about the inline assembler?
On Wednesday, 1 June 2016 at 23:23:49 UTC, ZILtoid1991 wrote: Here's the assembly code for my alpha-blending routine: Could you also paste the D version of your code? Perhaps the compiler (LDC, GDC) will generate similarly vectorized code that is inlinable, etc. -Johan
