July 11, 2016
On Monday, 11 July 2016 at 13:13:02 UTC, Patrick Schluter wrote:
>
> Because of attitudes like shown in that thread
> https://forum.dlang.org/post/ilbmfvywzktilhskpeoh@forum.dlang.org
> people who do not really understand why 32 bit systems are a really problematic even if the apps don't use more than 2 GiB of memory.
>
> Here's Linus Torvalds classic rant about 64 bit
> https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/  (it's more about PAE but the reasons why 64 bits is a good thing in general are the same: address space!)

Why can't you use both 32bit and 64bit pointers when compiling for x86_64?

My guess would be that using 64bit registers precludes the use of 32bit registers.
July 11, 2016
On Monday, 11 July 2016 at 17:14:17 UTC, jmh530 wrote:
> On Monday, 11 July 2016 at 13:13:02 UTC, Patrick Schluter wrote:
>>
>> Because of attitudes like shown in that thread
>> https://forum.dlang.org/post/ilbmfvywzktilhskpeoh@forum.dlang.org
>> people who do not really understand why 32 bit systems are a really problematic even if the apps don't use more than 2 GiB of memory.
>>
>> Here's Linus Torvalds classic rant about 64 bit
>> https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/  (it's more about PAE but the reasons why 64 bits is a good thing in general are the same: address space!)
>
> Why can't you use both 32bit and 64bit pointers when compiling for x86_64?
>
> My guess would be that using 64bit registers precludes the use of 32bit registers.

You can, but OSes usually give you randomized memory layout as a security measure.

July 11, 2016
On Monday, 11 July 2016 at 13:05:09 UTC, Russel Winder wrote:
>> Agreed. I don't know why golang guys bother about it.

Because they have nothing else to propose than massive goroutine orgy so they kind of have to make it work.

> Maybe because they are developing a language for the 1980s?
>
> ;-)

It's not like they are using the Plan9 toolchain...

Ho wait...

July 12, 2016
On Monday, 11 July 2016 at 13:13:02 UTC, Patrick Schluter wrote:
> (it's more about PAE but the reasons why 64 bits is a good thing in general are the same: address space!)

And what's with address space?
July 12, 2016
On Monday, 11 July 2016 at 17:23:49 UTC, Ola Fosheim Grøstad wrote:
>
> You can, but OSes usually give you randomized memory layout as a security measure.

What if the memory allocation scheme were something like: randomly pick memory locations below some threshold from the 32bit segment and then above the threshold pick from elsewhere?
July 12, 2016
On Tuesday, 12 July 2016 at 13:28:33 UTC, jmh530 wrote:
> On Monday, 11 July 2016 at 17:23:49 UTC, Ola Fosheim Grøstad wrote:
>>
>> You can, but OSes usually give you randomized memory layout as a security measure.
>
> What if the memory allocation scheme were something like: randomly pick memory locations below some threshold from the 32bit segment and then above the threshold pick from elsewhere?

One possible technique is to use contiguous "unmapped" memory areas that cover your worst case number of elements with a specific base and just use indexes instead of absolute addressing. That way you often can just use 16 bits typed addressing (assuming max 65535 objects of a given type + a null index).

The base address may then be injected (during linking or by using self-modifying code if the OS allows it) into the code segments. Or you could use TLS + indexing, or whatever the OS supports.

Using global 64 bit pointers is just for generality and to keep language-implementation simple.  It is not strictly hardware related if you have a MMU, nor directly related to machine language as such. For a statically typed language you could probably get away with 16 or 32 bits for typed pointers most of the time if the OS and language doesn't make it difficult (like the conservative D GC scan).


July 12, 2016
On Tuesday, 12 July 2016 at 13:28:33 UTC, jmh530 wrote:
> On Monday, 11 July 2016 at 17:23:49 UTC, Ola Fosheim Grøstad wrote:
>>
>> You can, but OSes usually give you randomized memory layout as a security measure.
>
> What if the memory allocation scheme were something like: randomly pick memory locations below some threshold from the 32bit segment and then above the threshold pick from elsewhere?

There is a mmap flag for this on linux.
July 14, 2016
On Saturday, 9 July 2016 at 17:41:59 UTC, Andrei Alexandrescu wrote:
> On 7/7/16 6:36 PM, Enamex wrote:
>> https://news.ycombinator.com/item?id=12042198
>>
>> ^ reposting a link in the right place.
>
> A very nice article and success story. We've had similar stories with several products at Facebook. There is of course the opposite view - an orders-of-magnitude improvement means there was quite a lot of waste just before that.
>
> I wish we could amass the experts able to make similar things happen for us.
>
>
> Andrei


Hello Andrei,

May only be slightly related, but when you talked about D vs Go vs Rust in that Quora answer (here: https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Andrei-Alexandrescu), I was thinking, okay, so D's GC seems to turned out not that great. But how about the idea of transplanting Rust's ownership system instead of trying to make the GC better?

Disclaimer: I know very little about D's possibly similar mechanisms.

Thanks,
Istvan

July 16, 2016
On Thursday, 14 July 2016 at 10:58:47 UTC, Istvan Dobos wrote:
>  I was thinking, okay, so D's GC seems to turned out not that great. But how about the idea of transplanting Rust's ownership system instead of trying to make the GC better?

This requires drastically changing 99% of the language and it's bringing not just the benefits but also all the pain coming with this ownership system. Productivity goes down, learning curve goes up. And it will be a very different language in the end, so you might want to just use Rust instead of trying to make D another Rust.
July 16, 2016
On Saturday, 16 July 2016 at 11:02:00 UTC, thedeemon wrote:
> On Thursday, 14 July 2016 at 10:58:47 UTC, Istvan Dobos wrote:
>>  I was thinking, okay, so D's GC seems to turned out not that great. But how about the idea of transplanting Rust's ownership system instead of trying to make the GC better?
>
> This requires drastically changing 99% of the language and it's bringing not just the benefits but also all the pain coming with this ownership system. Productivity goes down, learning curve goes up. And it will be a very different language in the end, so you might want to just use Rust instead of trying to make D another Rust.

Yes that's the case for Rust, but no one has proven yet that an ownership system needs to such a pain.

In fact someone recently proposed an idea for a readable ownership system:

http://forum.dlang.org/post/ensdiijttlpcwuhdfpuu@forum.dlang.org

and I believe that it's quite possible to improve over Rust and still having a productive language. In fact the simple `scope` statements are a first and excellent step on this journey ;-)