On Sunday, 11 June 2017 at 08:52:37 UTC, deadalnix wrote:
> I ended up doing my own. There are just no way to do it well without cent/ucent . Weka is running into the same problem for error correction.

 And what timing, I just finished getting it working with assembly and compatible versions. Seems 5x slower rather than the dreaded 50, but that's from testing factorial up to 100 (200ms vs 1,200ms).

 Anyways, here's how it is currently, most features are avaliable, need more tests and find occurrences where it doesn't work.

 https://github.com/rtcvb32/Side-Projects/blob/master/scaledint.d

 One note, to get the x86 assembly versions, use -version=Intel, I have it disabled so I can concentrate on the compatible version and switch between them on my machine. -debug includes a unittest that runs a factorial test

On Sunday, 11 June 2017 at 18:01:41 UTC, Era Scarecrow wrote:
>  Anyways, here's how it is currently, most features are avaliable, need more tests and find occurrences where it doesn't work.

 I should probably mention that's only for UCent, Cent isn't fully tested or implemented yet.

On Sunday, 11 June 2017 at 18:01:41 UTC, Era Scarecrow wrote:
>  And what timing, I just finished getting it working with assembly and compatible versions. Seems 5x slower rather than the dreaded 50, but that's from testing factorial up to 100 (200ms vs 1,200ms).

 Doing a 10240bit int I ran though 1,000 factorials in 6 seconds (this includes printing the values out). I got to about 400 in 16 minutes using the generic code. So like the wideint implementation I saw a while ago, larger types aren't recommended, but the speed penalty you can live with to use cent/ucent.

 Also got Cent working (mostly). In a few more days I should probably have this done. If there's somewhere else i should post my work regarding this or updates, do let me know.

On Sunday, 11 June 2017 at 21:52:40 UTC, Era Scarecrow wrote:
>  Also got Cent working (mostly).

 It's complete, more or less now. I just a matter of filling in any missing methods that I haven't programmed for, and probably adding filler/forwarding functions from ScaledInt to UScaledInt.

 Although I'm quite happy to change (ScaledInt) if someone has a better idea name idea.

 I'll be in the D IRC chat for the next week or so, so if anyone wants to talk to me directly... When it's good enough I'll submit my code to the std.experimental branch.

 Also I need to compile/test the asm, I don't have it set up here (can compile, can't run).

On Sunday, 11 June 2017 at 21:52:40 UTC, Era Scarecrow wrote:
>  Doing a 10240bit int I ran though 1,000 factorials in 6 seconds (this includes printing the values out). I got to about 400 in 16 minutes using the generic code.

 Got the compatible/generic code to run far faster, about 7 times slower vs the assembly language version!

 Probably the last of those optimizations I'll be making, don't think i can squeeze too much more out of it.

On Sunday, 11 June 2017 at 18:01:41 UTC, Era Scarecrow wrote:
> On Sunday, 11 June 2017 at 08:52:37 UTC, deadalnix wrote:
>> I ended up doing my own. There are just no way to do it well without cent/ucent . Weka is running into the same problem for error correction.
>
>  And what timing, I just finished getting it working with assembly and compatible versions. Seems 5x slower rather than the dreaded 50, but that's from testing factorial up to 100 (200ms vs 1,200ms).
>
>  Anyways, here's how it is currently, most features are avaliable, need more tests and find occurrences where it doesn't work.
>
>  https://github.com/rtcvb32/Side-Projects/blob/master/scaledint.d
>
>  One note, to get the x86 assembly versions, use -version=Intel, I have it disabled so I can concentrate on the compatible version and switch between them on my machine. -debug includes a unittest that runs a factorial test

You misunderstood. We need cent/ucent supported by the compiler to get to larger integral types efficiently. There are no ways around it. There are a ton of operations such as the X86 MUL which are able to produce a large multiplication into 2 registers. There are no way to leverage theses without compiler provided cent/ucent.

On Monday, 12 June 2017 at 13:41:36 UTC, deadalnix wrote:
> You misunderstood. We need cent/ucent supported by the compiler to get to larger integral types efficiently. There are no ways around it. There are a ton of operations such as the X86 MUL which are able to produce a large multiplication into 2 registers. There are no way to leverage these without compiler provided cent/ucent.

 Agreed. But until larger types are natively avaliable (either by simulation built into the compiler or by hardware registers) you gotta work with what you got.

On Monday, 12 June 2017 at 15:41:03 UTC, Era Scarecrow wrote:
> On Monday, 12 June 2017 at 13:41:36 UTC, deadalnix wrote:
>> You misunderstood. We need cent/ucent supported by the compiler to get to larger integral types efficiently. There are no ways around it. There are a ton of operations such as the X86 MUL which are able to produce a large multiplication into 2 registers. There are no way to leverage these without compiler provided cent/ucent.
>
>  Agreed. But until larger types are natively avaliable (either by simulation built into the compiler or by hardware registers) you gotta work with what you got.

I work with SDC on that one. That's the only reasonable path forward.

On Saturday, 10 June 2017 at 19:40:47 UTC, Andrei Alexandrescu wrote:
> That's cool as long as the assembler is guarded by version(X_86) and has a portable alternative. Where's the code?

 Should i do a pull request and push it under std.experimental? Also if it's going to get renamed to a better struct name, gotta decide that. I think ScaledInt is a bad name to describe what it really is.

 The code's about 50k...

 I could instead push for an alternative version if you'd like, rebuild from the skeleton of this code to put the assembly versions of add/sub/mul/div to handle any size, and the template would only generate code for how big the struct is and passing buffers around... might be cleaner that way. Would also be easier for ctfe to handle calling for statically known values at compile time...