January 04, 2018
On Saturday, 30 December 2017 at 16:59:41 UTC, aberba wrote:
> In this video[1] from 2016, developer talks about C++ memory safety features, meta-programming, maturity and few others as main reasons they choose it for developing their blockchain software (the way I got it from a quick view).
>
> Besides, D maturity (which I can't confirm or deny), what else does D miss to be considered a better alternative for blockchain in 2018?
>
> D is also more productive, has safety and unittest built-in.
>
>
> 1. https://www.youtube.com/watch?v=w4jq4frE5v4

I can talk about this first hand as I have a project running in D. However, I would sadly not recommend D ATM for such a project for 2 reasons:
1/ It is practically not possible to write efficient crypto routines without cent/ucent, short of writing them in asm.
2/ The network layer become very tedious very quick because of how broken shared is and because there is no ownership mechanism. While none of this is present in C++ it doesn't get in your way either.

I would *LOVE* to be able to use more D on a day to day basis, but these 2 problems make it very hard. It is especially sad considering 1/ could be solved very easily. It literally took me less than 1h to add support for it in SDC.
January 04, 2018
On 2018-01-04 14:42, deadalnix wrote:

> I would *LOVE* to be able to use more D on a day to day basis, but these 2 problems make it very hard. It is especially sad considering 1/ could be solved very easily. It literally took me less than 1h to add support for it in SDC.

There have been commits from the LDC developers related to cent/ucent fairly recently.

-- 
/Jacob Carlborg
January 04, 2018
On Thursday, 4 January 2018 at 13:42:10 UTC, deadalnix wrote:
> On Saturday, 30 December 2017 at 16:59:41 UTC, aberba wrote:
>> In this video[1] from 2016, developer talks about C++ memory safety features, meta-programming, maturity and few others as main reasons they choose it for developing their blockchain software (the way I got it from a quick view).
>>
>> Besides, D maturity (which I can't confirm or deny), what else does D miss to be considered a better alternative for blockchain in 2018?
>>
>> D is also more productive, has safety and unittest built-in.
>>
>>
>> 1. https://www.youtube.com/watch?v=w4jq4frE5v4
>
> I can talk about this first hand as I have a project running in D. However, I would sadly not recommend D ATM for such a project for 2 reasons:
> 1/ It is practically not possible to write efficient crypto routines without cent/ucent, short of writing them in asm.
> 2/ The network layer become very tedious very quick because of how broken shared is and because there is no ownership mechanism. While none of this is present in C++ it doesn't get in your way either.
>
> I would *LOVE* to be able to use more D on a day to day basis, but these 2 problems make it very hard. It is especially sad considering 1/ could be solved very easily. It literally took me less than 1h to add support for it in SDC.

Not a drama, can be solved, problems are opportunities


January 14, 2018
On 1/4/18 8:42 AM, deadalnix wrote:
> On Saturday, 30 December 2017 at 16:59:41 UTC, aberba wrote:
>> In this video[1] from 2016, developer talks about C++ memory safety features, meta-programming, maturity and few others as main reasons they choose it for developing their blockchain software (the way I got it from a quick view).
>>
>> Besides, D maturity (which I can't confirm or deny), what else does D miss to be considered a better alternative for blockchain in 2018?
>>
>> D is also more productive, has safety and unittest built-in.
>>
>>
>> 1. https://www.youtube.com/watch?v=w4jq4frE5v4
> 
> I can talk about this first hand as I have a project running in D. However, I would sadly not recommend D ATM for such a project for 2 reasons:
> 1/ It is practically not possible to write efficient crypto routines without cent/ucent, short of writing them in asm.
> 2/ The network layer become very tedious very quick because of how broken shared is and because there is no ownership mechanism. While none of this is present in C++ it doesn't get in your way either.
> 
> I would *LOVE* to be able to use more D on a day to day basis, but these 2 problems make it very hard. It is especially sad considering 1/ could be solved very easily. It literally took me less than 1h to add support for it in SDC.

Thanks for these thoughts!

* (u)cent support
* fixes for the shared qualifier
* ownership mechanism

These took less than 1h to add support for? That would be awesome... but realistically only the (u)cent sounds like that size of effort.

I've always wondered why we can't implement struct LargeInt(uint bytes) as a library mechanism for larged fixed-size integers, with asm specialization for LargeInt!8. Is adding the type to the compiler necessary, and if so, why?


Andrei
January 15, 2018
On Sun, 14 Jan 2018 18:03:27 -0500, Andrei Alexandrescu wrote:

> On 1/4/18 8:42 AM, deadalnix wrote:
>> I would *LOVE* to be able to use more D on a day to day basis, but these 2 problems make it very hard. It is especially sad considering 1/ could be solved very easily. It literally took me less than 1h to add support for it in SDC.
> 
> Thanks for these thoughts!
> 
> * (u)cent support * fixes for the shared qualifier * ownership mechanism
> 
> These took less than 1h to add support for? That would be awesome... but realistically only the (u)cent sounds like that size of effort.
> 

That's what he said: "... considering 1/ could be solved very easily. It literally took me less than 1h to add support for it in SDC."
January 15, 2018
On Sunday, 14 January 2018 at 23:03:27 UTC, Andrei Alexandrescu wrote:
> Thanks for these thoughts!
>
> * (u)cent support
> * fixes for the shared qualifier
> * ownership mechanism
>
> These took less than 1h to add support for? That would be awesome... but realistically only the (u)cent sounds like that size of effort.
>
> I've always wondered why we can't implement struct LargeInt(uint bytes) as a library mechanism for larged fixed-size integers, with asm specialization for LargeInt!8. Is adding the type to the compiler necessary, and if so, why?
>
>
> Andrei

That is the proposed path for bootstrapping the compiler.

See
https://github.com/d-gamedev-team/gfm/blob/master/integers/gfm/integers/wideint.d
https://github.com/dlang/dmd/pull/7699
and recent effort to have struct as the main integral type in the compiler.
January 18, 2018
On Sunday, 14 January 2018 at 23:03:27 UTC, Andrei Alexandrescu wrote:
> Thanks for these thoughts!
>
> * (u)cent support
> * fixes for the shared qualifier
> * ownership mechanism
>
> These took less than 1h to add support for? That would be awesome... but realistically only the (u)cent sounds like that size of effort.
>

Agreed. That would be already a plus, as it would allow to do all the crypto in D.

> I've always wondered why we can't implement struct LargeInt(uint bytes) as a library mechanism for larged fixed-size integers, with asm specialization for LargeInt!8. Is adding the type to the compiler necessary, and if so, why?
>

Asm specialization would not be ideal. Compilers have a pass called legalization where they break down the operation of types larger than the largest the plateform support into a series of operations on smaller types. It can generate specific pattern that the rest of the compiler is able to understand and optimize for.

This result in the use of instruction that would be very difficult for the compiler to reconstruct from the use of smaller integer types, such as mulhi.

Using asm is not ideal, unless the whole routine is written in asm, because the compiler find itself to optimize it, for instance after inlining. So even if it can inline - modern compiler can inline asm under specific circumstances, it finds itself unable to optimize operations at a higher level such as doing (a + b) + (c + d) instead of ((a + b) + c) + d.

Having larger types than 128 bits is not really necessary as you can leverage 128bits integers and do the magic yourself. For instance, to add two 256 bits integers represented as ulong[4], you can do:

ucent acc = 0;
ulong result[4];
for (i; 0 .. 4) {
    acc += a[i];
    acc += b[i];
    result[i] = cast(ulong) acc;
    acc >>= 64;
}

This will generate the ideal code on a modern optimizing compiler. Doing the same thing using only ulong will not generate good code as the compiler would have to understand from the techniques you used that you are indeed making addition porting the carry over. The problem gets even more hairy for multiplications.
January 18, 2018
On Thursday, 18 January 2018 at 03:19:57 UTC, deadalnix wrote:
> On Sunday, 14 January 2018 at 23:03:27 UTC, Andrei Alexandrescu wrote:
>> Thanks for these thoughts!
>>
>> * (u)cent support
>> * fixes for the shared qualifier
>> * ownership mechanism
>>
>> These took less than 1h to add support for? That would be awesome... but realistically only the (u)cent sounds like that size of effort.
>>
>
> Agreed. That would be already a plus, as it would allow to do all the crypto in D.
>

Reading this again, I think there is a bit of a misunderstanding. Only cent/ucent took me ~1h to implement. The rest is more complex. That being said, having cent/ucent would unlock a great deal of performance for crypto libraries, and this is where the bottleneck is as far as CPU is concerned in this type of application.

January 18, 2018
On 1/17/2018 7:22 PM, deadalnix wrote:
> Reading this again, I think there is a bit of a misunderstanding. Only cent/ucent took me ~1h to implement. The rest is more complex. That being said, having cent/ucent would unlock a great deal of performance for crypto libraries, and this is where the bottleneck is as far as CPU is concerned in this type of application.
> 

I don't remember how long, but it took me a fair while to do the divide:

  https://github.com/dlang/druntime/blob/master/src/rt/llmath.d

It could be upscaled by rote to 128 bits, but even that would take me much longer than an hour. And it would still leave the issue of making ucent work with 32 bit code gen.

It could also be translated to D, but I doubt the generated code would be as good.

Nevertheless, we do have the technology, we just need someone to put it together.
January 23, 2018
On Thursday, 18 January 2018 at 09:02:38 UTC, Walter Bright wrote:
> I don't remember how long, but it took me a fair while to do the divide:
>
>   https://github.com/dlang/druntime/blob/master/src/rt/llmath.d
>
> It could be upscaled by rote to 128 bits, but even that would take me much longer than an hour. And it would still leave the issue of making ucent work with 32 bit code gen.
>
> It could also be translated to D, but I doubt the generated code would be as good.
>
> Nevertheless, we do have the technology, we just need someone to put it together.

All the code to split 64 bits into 32 bits was generic and could be reused.
1 2
Next ›   Last »