subject:"Tail pad optimization, cache friendlyness and C\+\+ interrop"

On 06/19/2014 11:28 PM, "Ola Fosheim Grøstad" 
" wrote:

But we aren't talking machine language, we are talking D.


This part is spot on.

Re: Tail pad optimization, cache friendlyness and C++ interrop

On 06/19/2014 10:39 PM, "Ola Fosheim Grøstad" 
" wrote:

On Thursday, 19 June 2014 at 20:26:27 UTC, Timon Gehr wrote:

...
No, your line of reasoning is flawed. The amount of resources is not a
constant. You must prove that memory safety holds for


I have not set out to prove anything,


This is a discussion about proving memory safety.
(Though this is not at all apparent from the original topic. This sort 
of went out of hand. :o))



I dislike how people abuse CS in order to "win" an argument.


Sorry for having "won" the argument if that is what you are implying. 
That was not my intention and this is not actually a contest. My 
intention was to defend the use of properties of Turing machines in the 
context of a Turing complete programming language. I wanted to convey 
the message that it has no "issues" and it is not "fundamentally 
flawed". I also don't think I am guilty of "abuse".



If you guys want to leverage CS theory do it
properly or leave it out. Just because you have read Garey and Johnson


I haven't, if that helps.


does not mean that you should leverage it without proper treatment.


I failed to decipher this part of the sentence. Is it just some more 
boring name calling or is there an insight behind it?



NB: I have started to write down a complete-ish list of @safe language 
features and I will post them to the issue opened by H.S. Teoh soon.

Re: Tail pad optimization, cache friendlyness and C++ interrop

On Thursday, 19 June 2014 at 20:47:16 UTC, H. S. Teoh via 
Digitalmars-d wrote:
programs!). So the only remaining approach is to consider all 
possible
programs. Which means you have to implement exhaustive state 
space

search. Which is impractical for the reasons I stated.


No. Is a program compiled to asm.js memory safe? It has to be, 
because Javascript is a memory safe environment.  You might still 
mess up badly, but you can obviously transform just about any 
program that is presumed to be memory unsafe into one that is 
memory safe (if you consider a function to be a mapping of input 
to output).


Are you telling me that you cannot write an equivalent mapping 
from input to output using memory safe primitives while staying 
within P? You can safely insist on only having access to valid 
memory safe primitives within @safe and still be able to solve 
the exact same problems, in pretty much the same way (on an 
abstract algorithmic level).


It's not like @safe guards against exceptions IIRC. You can 
inject bound checks everywhere and it is provable memory safe. 
@safe should guarantee that your program terminates in an orderly 
fashion without corrupting memory. @safe does not guarantee 
correctness. That would be a folly.


A hypothetical and pointless "not @safe" does not guarantee 
memory corruption either. If you compile to asm.js you obviously 
always stay memory safe.


Or do you define "out of array bounds" exceptions as memory 
corruption?


Now, if we were talking untransformable machine language, you 
might have a point, not sure. But we aren't talking machine 
language, we are talking D.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-19 Thread H. S. Teoh via Digitalmars-d

On Thu, Jun 19, 2014 at 08:31:53PM +, via Digitalmars-d wrote:
> On Thursday, 19 June 2014 at 19:37:32 UTC, H. S. Teoh via Digitalmars-d
> wrote:
> >But the non-solvability of the halting problem means that there is no
> >algorithm that can compress every possible program.
> 
> Even if true, programmers don't write every possible program when they
> try to write @safe code.

So how do you, as a compiler writer, predict exactly which programs your
users will write? -- because without knowing that, you cannot know which
analysis algorithms to implement that will solve the N-step halting
problem for all the programs that users will write (even though that's
only a very small finite set out of the space of all possible
programs!). So the only remaining approach is to consider all possible
programs. Which means you have to implement exhaustive state space
search. Which is impractical for the reasons I stated.

T

-- 
This is a tpyo.

Re: Tail pad optimization, cache friendlyness and C++ interrop

On 06/19/2014 09:06 PM, "Ola Fosheim Grøstad" 
" wrote:

On Thursday, 19 June 2014 at 18:25:00 UTC, Tobias Pankrath wrote:

It's not. Since the resources to verify a property are limited, too.

If I need to enumerate all possible program states, there will always
exists a program that can run on my box but will not be verifiable on
it (since I lack the resources).


Nobody have said you should enumerate all possible states.

There's a significant difference between a proof and an algorithm.


I don't think it is that significant. They are basically the same except 
that the proof is typically more strongly typed and you cannot actually 
execute a proof by excluded middle in the general case.

Re: Tail pad optimization, cache friendlyness and C++ interrop


On Thursday, 19 June 2014 at 20:26:27 UTC, Timon Gehr wrote:

I assume you mean @safe <===> memory safety.


I mean that the best route in general is: @safe => memory safe 
features on the local level (trivial) => "strength reduction" 
into memory safe use of memory unsafe features (trivial).


No, your line of reasoning is flawed. The amount of resources 
is not a constant. You must prove that memory safety holds for


I have not set out to prove anything, I dislike how people abuse 
CS in order to "win" an argument. If you guys want to leverage CS 
theory do it properly or leave it out. Just because you have read 
Garey and Johnson does not mean that you should leverage it 
without proper treatment.

Re: Tail pad optimization, cache friendlyness and C++ interrop

On Thursday, 19 June 2014 at 19:37:32 UTC, H. S. Teoh via 
Digitalmars-d wrote:
But the non-solvability of the halting problem means that there 
is no

algorithm that can compress every possible program.


Even if true, programmers don't write every possible program when 
they try to write @safe code.

Re: Tail pad optimization, cache friendlyness and C++ interrop

On 06/19/2014 06:06 AM, "Ola Fosheim Grøstad" 
" wrote:

...
In the real world you work with typical programs that run on finite
resources guided by heuristics. There is no proof that you cannot have
@safe.


I assume you mean @safe <===> memory safety.


So leave that line of arguing. It is fundamentally flawed.


No, your line of reasoning is flawed. The amount of resources is not a 
constant. You must prove that memory safety holds for _each possible_ 
amount of resources at which point you haven't won anything by talking 
about resource usage, or else you need to set an explicit resource bound 
_at the language level_ and enforce it.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-19 Thread deadalnix via Digitalmars-d


On Thursday, 19 June 2014 at 19:12:53 UTC, Ola Fosheim Grøstad
wrote:
You are being silly. You either discuss computability or you 
discuss complexity. Please don't mix the two topics.




Do you have something to contribute to THIS discussion, or ill
you continue to bring irrelevant topic in ?

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-19 Thread Joakim via Digitalmars-d


On Thursday, 19 June 2014 at 18:10:57 UTC, Walter Bright wrote:

On 6/19/2014 4:12 AM, Artur Skawina via Digitalmars-d wrote:

On 06/18/14 18:42, Dicebot via Digitalmars-d wrote:
On Wednesday, 18 June 2014 at 11:09:14 UTC, Artur Skawina via 
Digitalmars-d wrote:

The number of potential contributors is
already low enough, and the fuzzy licensing situation drives 
away the
most valuable ones (since those will often be the ones which 
treat the
legal aspects seriously and the risks involved when dealing 
with this
kind of mixed free and proprietary code within one repo are 
too high).


Wait what? Do you know a single person who decided to not 
work on DMD FE because of kind of formally (but not 
practically) non-free backend?


Well, do you think I would have said what I did if this issue 
didn't

affect /me/? [1]


The front end is now Boost licensed.


Admittedly his concerns are unclear, but his problem is with the 
backend, not the frontend, which he already said he likes better 
now that it's boost-licensed.  He claims that the proprietary 
backend scares potential contributors away and that it should be 
"split up" from the frontend, by which he might mean putting it 
in a separate git repo?


I don't know enough about these copyright tainting concerns to 
say if it's a good idea, just pointing out that he was talking 
about the backend, not the frontend.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-19 Thread H. S. Teoh via Digitalmars-d

On Thu, Jun 19, 2014 at 07:12:52PM +, via Digitalmars-d wrote:
> On Thursday, 19 June 2014 at 18:50:27 UTC, H. S. Teoh via Digitalmars-d
> wrote:
> >Exactly.  Just because something is *finite*, doesn't necessarily
> >mean it's practical.  Anything that requires enumeration of all
> >possible states is impractical, because it has an exponential worst
> >case bound, which is unacceptable for compilation time (or for
> >anything, really, except in the most trivial cases).
> 
> You are being silly. You either discuss computability or you discuss
> complexity. Please don't mix the two topics.
> 
> You either discuss a useful verification of safe features or you
> don't.
> 
> It's not at all impossible to verify memory safety for real time
> applications. Real time applications have an upper bound on how long
> they should run. This even holds for TMs.
> 
> The problem "does the TM terminate within N steps" is decidable.

Decidable doesn't mean feasible. You have to run a simulator of the
program for N steps in order to determine whether it terminates. If N is
large, this means compilation will be impractically slow.

The halting problem is not just about needing infinite time, it's also
about the non-existence of algorithms that can analyze every possible
program. Even if a given TM never terminates, as long as it fits into an
analysable pattern, we can prove its non-termination in finite time. The
analysing algorithm is able to "compress" the proof into finite length.
But the non-solvability of the halting problem means that there is no
algorithm that can compress every possible program. This means there is
no such algorithm that can determine termination within N steps for
arbitrary N, except the one that enumerates all possible states up to N
steps. If I have code like this:

while (!finished) {
if (arbitarilyComplexFalseCondition)
unsafeOperation();
else
safeOperation();

finished = arbitrarilyComplexStoppingCondition;
}

you cannot, in general, prove safety without enumerating all possible
states (since you can't predict which branch the if statement will
take). Since enumerating all possible states is impractical, this means
your N-step termination problem is practically unsolvable, even if it's
decidable in theory.

T

-- 
The early bird gets the worm. Moral: ewww...

Re: Tail pad optimization, cache friendlyness and C++ interrop

On Thursday, 19 June 2014 at 18:50:27 UTC, H. S. Teoh via 
Digitalmars-d wrote:
Exactly.  Just because something is *finite*, doesn't 
necessarily mean
it's practical.  Anything that requires enumeration of all 
possible
states is impractical, because it has an exponential worst case 
bound,
which is unacceptable for compilation time (or for anything, 
really,

except in the most trivial cases).


You are being silly. You either discuss computability or you 
discuss complexity. Please don't mix the two topics.


You either discuss a useful verification of safe features or you 
don't.


It's not at all impossible to verify memory safety for real time 
applications. Real time applications have an upper bound on how 
long they should run. This even holds for TMs.


The problem "does the TM terminate within N steps" is decidable.

Re: Tail pad optimization, cache friendlyness and C++ interrop


On Thursday, 19 June 2014 at 18:25:00 UTC, Tobias Pankrath wrote:
It's not. Since the resources to verify a property are limited, 
too.


If I need to enumerate all possible program states, there will 
always exists a program that can run on my box but will not be 
verifiable on it (since I lack the resources).


Nobody have said you should enumerate all possible states.

There's a significant difference between a proof and an algorithm.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-19 Thread H. S. Teoh via Digitalmars-d

On Thu, Jun 19, 2014 at 06:24:59PM +, Tobias Pankrath via Digitalmars-d 
wrote:
> On Thursday, 19 June 2014 at 04:06:51 UTC, Ola Fosheim Grøstad wrote:
> >On Wednesday, 18 June 2014 at 21:57:40 UTC, deadalnix wrote:
> >>Granted infinite resources. Good, now that we ruled that thing out,
> >>can we talk about the subject, or do we need to continue talking
> >>about imaginary things ?
> >
> >No, finite resources, and that is only a worst case upper bound. It
> >does not preclude the possibility of doing better. It also does not
> >say how much work it is in the typical case e.g. the kind of programs
> >you wrote when you try to make code @safe.
> >
> >What it does prove is that the problem is computable, that is a major
> >difference. Please note that the halting problem does not address
> >difficulty but analytical computability.
> >
> >In the real world you work with typical programs that run on finite
> >resources guided by heuristics. There is no proof that you cannot
> >have @safe. So leave that line of arguing. It is fundamentally
> >flawed.
> 
> It's not. Since the resources to verify a property are limited, too.
> 
> If I need to enumerate all possible program states, there will always
> exists a program that can run on my box but will not be verifiable on
> it (since I lack the resources).
> 
> It's also not enough for @safe to be verifiable, it should not slow
> down the compilation time too much as well.

Exactly.  Just because something is *finite*, doesn't necessarily mean
it's practical.  Anything that requires enumeration of all possible
states is impractical, because it has an exponential worst case bound,
which is unacceptable for compilation time (or for anything, really,
except in the most trivial cases).

To get an idea of how intractible it can get, suppose your entire
program state is fully described by, say, 1 MB worth of variables
(that's pretty conservative, considering the size of programs these days
and the size of the data they deal with). The upper bound to enumerating
all program states is 2^(1 MB) = 2^2^20 = ... (a number with 324,936
digits). Note that that's not 324,936 *states*, but that's the number of
*digits* in the number of states! It's a finite number, sure, but good
luck enumerating all program states within the lifetime of the universe
(don't even talk about within your lifetime!).

Even if you run it on a hypothetical distributed supercomputer with 100
billion nodes, that barely even begins to make a dent in the number of
states you need to evaluate (the number of states per node is a number
with "only" 324,925 digits, haha).

And mind you, 1 MB of state is pathetically small. Real programs these
days require GB's of memory, and that will cause the number of states to
explode far, far beyond any imaginable computing capabilities of the
human race, past, present, or future -- unless we manage to invent a
device that exploits time contraction near a black hole's horizon to
compute the halting problem in finite time (i.e., it's pure fiction).

T

-- 
Question authority. Don't ask why, just do it.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-19 Thread Tobias Pankrath via Digitalmars-d

On Thursday, 19 June 2014 at 04:06:51 UTC, Ola Fosheim Grøstad 
wrote:

On Wednesday, 18 June 2014 at 21:57:40 UTC, deadalnix wrote:

Granted infinite resources. Good, now that we ruled that thing
out, can we talk about the subject, or do we need to continue
talking about imaginary things ?


No, finite resources, and that is only a worst case upper 
bound. It does not preclude the possibility of doing better. It 
also does not say how much work it is in the typical case e.g. 
the kind of programs you wrote when you try to make code @safe.


What it does prove is that the problem is computable, that is a 
major difference. Please note that the halting problem does not 
address difficulty but analytical computability.


In the real world you work with typical programs that run on 
finite resources guided by heuristics. There is no proof that 
you cannot have @safe. So leave that line of arguing. It is 
fundamentally flawed.


It's not. Since the resources to verify a property are limited, 
too.


If I need to enumerate all possible program states, there will 
always exists a program that can run on my box but will not be 
verifiable on it (since I lack the resources).


It's also not enough for @safe to be verifiable, it should not 
slow down the compilation time too much as well.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-19 Thread Walter Bright via Digitalmars-d


On 6/19/2014 4:12 AM, Artur Skawina via Digitalmars-d wrote:

On 06/18/14 18:42, Dicebot via Digitalmars-d wrote:

On Wednesday, 18 June 2014 at 11:09:14 UTC, Artur Skawina via Digitalmars-d 
wrote:

The number of potential contributors is
already low enough, and the fuzzy licensing situation drives away the
most valuable ones (since those will often be the ones which treat the
legal aspects seriously and the risks involved when dealing with this
kind of mixed free and proprietary code within one repo are too high).


Wait what? Do you know a single person who decided to not work on DMD FE 
because of kind of formally (but not practically) non-free backend?


Well, do you think I would have said what I did if this issue didn't
affect /me/? [1]


The front end is now Boost licensed.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-19 Thread Artur Skawina via Digitalmars-d

On 06/18/14 18:42, Dicebot via Digitalmars-d wrote:
> On Wednesday, 18 June 2014 at 11:09:14 UTC, Artur Skawina via Digitalmars-d 
> wrote:
>> The number of potential contributors is
>> already low enough, and the fuzzy licensing situation drives away the
>> most valuable ones (since those will often be the ones which treat the
>> legal aspects seriously and the risks involved when dealing with this
>> kind of mixed free and proprietary code within one repo are too high).
> 
> Wait what? Do you know a single person who decided to not work on DMD FE 
> because of kind of formally (but not practically) non-free backend?

Well, do you think I would have said what I did if this issue didn't
affect /me/? [1]

The problem is a very practical one. Walter's complaint about the
lack of constructive contributions is justified; most of the language
related discussions happening here are nothing more than wish lists.
There are many different causes, I'm pointing out one.
What's unique about this one is that there's only one person in the
world that can do something about it -- the same task done by someone
other than Walter Bright would not be equally valuable.

The shared frontend+backend setup might not be just convenience, but
a deliberate attempt to discourage certain developments -- even then,
I think it does much more harm than good. It practically inhibits
"casual" contributions, while not really restricting usages that bring
few benefits to the original project. 

And, yes, some people really always check licenses, even before fully
determining what a software project actually is/does. Because if the
license is problematic then everything else is irrelevant -- the project
simply is unusable, and any time spent looking at it would be wasted.

That is fortunately not a problem for dmdfe, as boost/gpl should be
ok for (almost) everyone. But the cost of having to deal with another
license, for a bundled part, that you're never going to use and are not
even interested in, is there. The cost of scratching-an-itch also
becomes higher. Depending on person/context, these costs can be
prohibitive.

artur

[1] If I knew I would be replying like this, I would have worded that
quoted statement a bit differently; I'm not quite that arrogant. :)

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/18/2014 10:18 AM, H. S. Teoh via Digitalmars-d wrote:

Everyone talks about it, but nobody does anything about it, so here goes
nothing:

https://issues.dlang.org/show_bug.cgi?id=12941

Obviously, I have no idea what should go in that list, so everyone who
cares about this issue, please chime in. Thanks!

P.S. I've also tagged a whole bunch of issues with 'safe'. It's just
based on a quick skim over all issues that turned up when I searched for
'safe', so I may have mistagged some, and missed others, but this is
just to get the ball rolling. Please fix wrong/missing tags if you find
them. :)


Thanks!

Re: Tail pad optimization, cache friendlyness and C++ interrop


On Wednesday, 18 June 2014 at 21:57:40 UTC, deadalnix wrote:

Granted infinite resources. Good, now that we ruled that thing
out, can we talk about the subject, or do we need to continue
talking about imaginary things ?


No, finite resources, and that is only a worst case upper bound. 
It does not preclude the possibility of doing better. It also 
does not say how much work it is in the typical case e.g. the 
kind of programs you wrote when you try to make code @safe.


What it does prove is that the problem is computable, that is a 
major difference. Please note that the halting problem does not 
address difficulty but analytical computability.


In the real world you work with typical programs that run on 
finite resources guided by heuristics. There is no proof that you 
cannot have @safe. So leave that line of arguing. It is 
fundamentally flawed.

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/18/2014 2:16 AM, Rikki Cattermole wrote:

 From my experience, one of the reasons I haven't had much to do with the
development of dmd is simply to compile dmd, druntime is not as straight forward
as it could be.


You don't need to actually hack on dmd or druntime to make valuable 
contributions. Getting problem reports and reproducible test cases into bugzilla 
is much needed work, for example.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread deadalnix via Digitalmars-d


On Wednesday, 18 June 2014 at 20:58:46 UTC, Ola Fosheim Grøstad
wrote:

On Wednesday, 18 June 2014 at 15:25:11 UTC, Luís Marques wrote:

Maybe I missed something in this discussion, but unless you are
not including jumps/loops in those N instructions, just because
the number of instructions and memory is bounded does not mean
you can prove (for arbitrary programs) that the program
terminates.


Yes, you can. You just run it until it enters a previous state. 
At that point you have an infinite loop and it won't terminate.


Since you only have a finite number of possible states and you 
always move from one state to another the proof of this becomes 
trivial. The worst case time complexity is the same as the 
number of possible states.


Granted infinite resources. Good, now that we ruled that thing
out, can we talk about the subject, or do we need to continue
talking about imaginary things ?

Re: Tail pad optimization, cache friendlyness and C++ interrop


On Wednesday, 18 June 2014 at 15:25:11 UTC, Luís Marques wrote:

Maybe I missed something in this discussion, but unless you are
not including jumps/loops in those N instructions, just because
the number of instructions and memory is bounded does not mean
you can prove (for arbitrary programs) that the program
terminates.


Yes, you can. You just run it until it enters a previous state. 
At that point you have an infinite loop and it won't terminate.


Since you only have a finite number of possible states and you 
always move from one state to another the proof of this becomes 
trivial. The worst case time complexity is the same as the number 
of possible states.

Re: Tail pad optimization, cache friendlyness and C++ interrop


On Wednesday, 18 June 2014 at 19:17:50 UTC, Marc Schütz wrote:
Jumps and loops don't matter. The point is that such a program 
only has a finite amount of possible states: The 4 bytes of 
RAM, plus the current instruction pointer (to be 2 bits for 4 
instructions). In this case, there are only


2^(4*8) * 2^2 = 2^34 = 17179869184

different states. If during execution you encounter a state 
that you've already seen before, you know that the program will 
go into an infinite loop. This is easy to implement using a 
bitmap.


Of course, said bitmap will soon become too large to handle in 
practice if you want to analyze realistic "interesting" 
programs.


Ah, right, my bad :-)

Re: Tail pad optimization, cache friendlyness and C++ interrop


On Wednesday, 18 June 2014 at 15:25:11 UTC, Luís Marques wrote:

On Wednesday, 18 June 2014 at 06:35:01 UTC, Ola Fosheim Grøstad
wrote:
Not really, you can prove termination for all programs with 3 
instructions and 3 bytes of RAM. You can do it for all 
programs with 4 instructions and 4 bytes of RAM. You can do it 
for all programs with N instructions and N bytes of RAM. You 
cannot do it for all TMs since they have unbounded storage.


Thus you can prove non-trivial properties such as whether a 
functions returns with 1, whether it accepts or rejects the 
input '0', etc. It might take a lot of time, but you can do it 
in a fixed amount of time. You cannot do it for TMs.


Maybe I missed something in this discussion, but unless you are
not including jumps/loops in those N instructions, just because
the number of instructions and memory is bounded does not mean
you can prove (for arbitrary programs) that the program
terminates.



Jumps and loops don't matter. The point is that such a program 
only has a finite amount of possible states: The 4 bytes of RAM, 
plus the current instruction pointer (to be 2 bits for 4 
instructions). In this case, there are only


2^(4*8) * 2^2 = 2^34 = 17179869184

different states. If during execution you encounter a state that 
you've already seen before, you know that the program will go 
into an infinite loop. This is easy to implement using a bitmap.


Of course, said bitmap will soon become too large to handle in 
practice if you want to analyze realistic "interesting" programs.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread H. S. Teoh via Digitalmars-d

On Wed, Jun 18, 2014 at 04:39:27PM +, Dicebot via Digitalmars-d wrote:
> On Wednesday, 18 June 2014 at 07:05:13 UTC, deadalnix wrote:
> >On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright wrote:
> >>On 6/17/2014 11:50 PM, deadalnix wrote:
> >>>and the fact that @safe is defined backward (ie by listing what is not
> >>>allowed and
> >>>adding to the list when new holes are discovered
> >>
> >>https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe%2C%20&keywords_type=allwords&list_id=41168&query_format=advanced
> >>
> >>Currently, there are zero bugzilla issues tagged with 'safe'. Please
> >>file bugzilla issues for which ones are discovered and tag them!
> >
> >I don't even know what to answer to that. We are clearly talking past
> >each other here, and I have no idea how to convey the message in a
> >better way.
> 
> Create a bugzilla issue to make everything unsafe and list there
> constructs you think can be defined as safe :)

Everyone talks about it, but nobody does anything about it, so here goes
nothing:

https://issues.dlang.org/show_bug.cgi?id=12941

Obviously, I have no idea what should go in that list, so everyone who
cares about this issue, please chime in. Thanks!

P.S. I've also tagged a whole bunch of issues with 'safe'. It's just
based on a quick skim over all issues that turned up when I searched for
'safe', so I may have mistagged some, and missed others, but this is
just to get the ball rolling. Please fix wrong/missing tags if you find
them. :)

T

-- 
I'm still trying to find a pun for "punishment"...

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread Dicebot via Digitalmars-d

On Wednesday, 18 June 2014 at 11:09:14 UTC, Artur Skawina via 
Digitalmars-d wrote:

The number of potential contributors is
already low enough, and the fuzzy licensing situation drives 
away the
most valuable ones (since those will often be the ones which 
treat the
legal aspects seriously and the risks involved when dealing 
with this
kind of mixed free and proprietary code within one repo are too 
high).


Wait what? Do you know a single person who decided to not work on 
DMD FE because of kind of formally (but not practically) non-free 
backend?

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread Dicebot via Digitalmars-d


On Wednesday, 18 June 2014 at 07:05:13 UTC, deadalnix wrote:

On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright wrote:

On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing 
what is not allowed and

adding to the list when new holes are discovered


https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe%2C%20&keywords_type=allwords&list_id=41168&query_format=advanced

Currently, there are zero bugzilla issues tagged with 'safe'. 
Please file bugzilla issues for which ones are discovered and 
tag them!


I don't even know what to answer to that. We are clearly 
talking past each other here, and I have no idea how to convey 
the message in a better way.


Create a bugzilla issue to make everything unsafe and list there 
constructs you think can be defined as safe :)

Re: Tail pad optimization, cache friendlyness and C++ interrop


On Wednesday, 18 June 2014 at 06:35:01 UTC, Ola Fosheim Grøstad
wrote:
Not really, you can prove termination for all programs with 3 
instructions and 3 bytes of RAM. You can do it for all programs 
with 4 instructions and 4 bytes of RAM. You can do it for all 
programs with N instructions and N bytes of RAM. You cannot do 
it for all TMs since they have unbounded storage.


Thus you can prove non-trivial properties such as whether a 
functions returns with 1, whether it accepts or rejects the 
input '0', etc. It might take a lot of time, but you can do it 
in a fixed amount of time. You cannot do it for TMs.


Maybe I missed something in this discussion, but unless you are
not including jumps/loops in those N instructions, just because
the number of instructions and memory is bounded does not mean
you can prove (for arbitrary programs) that the program
terminates.

I hope I don't shoot myself in the foot by trying to come up with
a concrete example, but let me try. Consider the program to
calculate whether some point is part of the Mandelbrot set. The
program only requires a small and fixed amount of memory but for
some points it may iterate forever (practical fractal programs
set an iteration limit, but let's assume this one doesn't, for
the sake of the argument).

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread Matthias Bentrup via Digitalmars-d

On Wednesday, 18 June 2014 at 08:13:59 UTC, Walter Bright wrote:

On 6/18/2014 12:05 AM, deadalnix wrote:
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright
wrote:

On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing
what is not

allowed and
adding to the list when new holes are discovered

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe%2C%20&keywords_type=allwords&list_id=41168&query_format=advanced

Currently, there are zero bugzilla issues tagged with 'safe'.
Please file

bugzilla issues for which ones are discovered and tag them!

I don't even know what to answer to that. We are clearly
talking past each other
here, and I have no idea how to convey the message in a better
way.

1. A long list of problems with @safe has been asserted, but I
have not been able to elicit any enumeration of them, so the
extent of this problem is completely unknown.

2. The definition of @safe in the spec is asserted to be
utterly wrong, but no corrected definition has been proposed.

3. A new approach to designing @safe has been proposed in vague
terms, but nothing specific and no offers of help to flesh it
out.

From my perspective, it is like bug reports I'd often get for
the compiler that consisted solely of:

"Your compiler doesn't work."

It's just not helpful. There's nothing I can do with that.

Also, D is a collaborative effort. If there's an issue that
engages your interest, step up and help out. I simply cannot do
everything. This n.g. is full of "you should do this, you
should do that" largely directed at me. You guys want things to
happen, make them happen!

You two speak different languages here, I'll try to translate:

Basically deadalnix argues that memory safety cannot be checked
by a machine (there's a proof for that) and as @safe-ness can be
checked it obviously is not equivalent to memory safety. Further
*any* definition of @safe-ness that can be expressed by a finite
set of mathematical rules will not be equivalent to memory safety.

Then the big misunderstanding is the "equivalence". Equivalence
means that

1) @safe implies memory-safe
2) !@safe implies !memory-safe

Clearly Walter is only talking about 1), and there is no reason
why you couldn't have a @safe-ness check that implies
memory-safety. It just won't be *equivalent*.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread Artur Skawina via Digitalmars-d

On 06/18/14 10:14, Walter Bright via Digitalmars-d wrote:
> 
> Also, D is a collaborative effort. If there's an issue that engages your 
> interest, step up and help out. I simply cannot do everything. This n.g. is 
> full of "you should do this, you should do that" largely directed at me. You 
> guys want things to happen, make them happen!

And most of those requests completely ignore language context, are
indiscriminately trying to copy or transplant other concepts, or give
a suboptimal answer to the wrong question. It's frustrating to even
just read them; I have several times considered unsubscribing, as 
watching things go in a wrong and very unproductive direction isn't
fun.

The one thing that /you/ could do, which would make the most difference,
is splitting up the compiler into a free frontend [1] and the non-free
"rest". The current situation results in people avoiding looking at or
even going near DMD at all. The number of potential contributors is
already low enough, and the fuzzy licensing situation drives away the
most valuable ones (since those will often be the ones which treat the
legal aspects seriously and the risks involved when dealing with this
kind of mixed free and proprietary code within one repo are too high).

(JIC someone suggests working on the frontend via LDC/GDC trees - that
would inevitably result in a language fork eventually.)

artur

[1] the many problems with the artistic license are now gone, after the
switch to boost; at least the license itself is no longer an issue.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread Joakim via Digitalmars-d

On Wednesday, 18 June 2014 at 09:16:32 UTC, Rikki Cattermole 
wrote:
From my experience, one of the reasons I haven't had much to do 
with the development of dmd is simply to compile dmd, druntime 
is not as straight forward as it could be.
All I can say is with ddmd make it compilable with dub same 
goes with druntime. With a nice tutorial on how to set it all 
up on Windows/Linux ext.
Preferably with a nice automated means of, this is how we make 
a release build for platform x.


I used this guide from the wiki some time back to start building 
dmd/druntime/phobos and run their tests, pretty easy:


http://wiki.dlang.org/Building_DMD

Non-Windows builds are very easy.  Windows builds require a bit 
too much manual configuration, I'll agree with that.


It'll go along way. It really would. And anyway it'll really 
show off the power of dub ;)


Daniel should stick his D frontend up there as a library, even if 
it isn't architected to be used as a library right now.  People 
will find ways to use it and his translated code will get some 
testing.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread Rikki Cattermole via Digitalmars-d


On 18/06/2014 8:52 p.m., Joakim wrote:

On Wednesday, 18 June 2014 at 08:13:59 UTC, Walter Bright wrote:

From my perspective, it is like bug reports I'd often get for the
compiler that consisted solely of:

"Your compiler doesn't work."

It's just not helpful. There's nothing I can do with that.


Lol, I'd love to see your response to them.


Also, D is a collaborative effort. If there's an issue that engages
your interest, step up and help out. I simply cannot do everything.
This n.g. is full of "you should do this, you should do that" largely
directed at me. You guys want things to happen, make them happen!


I largely agree with this assessment, but would also like to point out
that while almost all programmers use compilers, very few know how to
improve one.  You can help by fleshing out the dmd source guide so that
it's better, then pointing people at it when they demand stuff from you: ;)

http://wiki.dlang.org/DMD_Source_Guide

I know, more work for you and the few dmd contributors, but you guys can
help others get involved with better documentation for dmd.


From my experience, one of the reasons I haven't had much to do with 
the development of dmd is simply to compile dmd, druntime is not as 
straight forward as it could be.
All I can say is with ddmd make it compilable with dub same goes with 
druntime. With a nice tutorial on how to set it all up on Windows/Linux ext.
Preferably with a nice automated means of, this is how we make a release 
build for platform x.


It'll go along way. It really would. And anyway it'll really show off 
the power of dub ;)


But in saying all this, I may want to learn to write my own compiler 
ext. I just don't have the knowledge and even getting into x86 
instruction encoding is head hurting alone as it stands.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread Joakim via Digitalmars-d


On Wednesday, 18 June 2014 at 08:13:59 UTC, Walter Bright wrote:
From my perspective, it is like bug reports I'd often get for 
the compiler that consisted solely of:


"Your compiler doesn't work."

It's just not helpful. There's nothing I can do with that.


Lol, I'd love to see your response to them.

Also, D is a collaborative effort. If there's an issue that 
engages your interest, step up and help out. I simply cannot do 
everything. This n.g. is full of "you should do this, you 
should do that" largely directed at me. You guys want things to 
happen, make them happen!


I largely agree with this assessment, but would also like to 
point out that while almost all programmers use compilers, very 
few know how to improve one.  You can help by fleshing out the 
dmd source guide so that it's better, then pointing people at it 
when they demand stuff from you: ;)


http://wiki.dlang.org/DMD_Source_Guide

I know, more work for you and the few dmd contributors, but you 
guys can help others get involved with better documentation for 
dmd.

Re: Tail pad optimization, cache friendlyness and C++ interrop

On 6/18/2014 12:05 AM, deadalnix wrote:

On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright wrote:

On 6/17/2014 11:50 PM, deadalnix wrote:

and the fact that @safe is defined backward (ie by listing what is not
allowed and
adding to the list when new holes are discovered

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe%2C%20&keywords_type=allwords&list_id=41168&query_format=advanced

Currently, there are zero bugzilla issues tagged with 'safe'. Please file
bugzilla issues for which ones are discovered and tag them!

I don't even know what to answer to that. We are clearly talking past each other
here, and I have no idea how to convey the message in a better way.

1. A long list of problems with @safe has been asserted, but I have not been
able to elicit any enumeration of them, so the extent of this problem is
completely unknown.

2. The definition of @safe in the spec is asserted to be utterly wrong, but no
corrected definition has been proposed.

3. A new approach to designing @safe has been proposed in vague terms, but
nothing specific and no offers of help to flesh it out.

From my perspective, it is like bug reports I'd often get for the compiler that
consisted solely of:

"Your compiler doesn't work."

It's just not helpful. There's nothing I can do with that.

Also, D is a collaborative effort. If there's an issue that engages your
interest, step up and help out. I simply cannot do everything. This n.g. is full
of "you should do this, you should do that" largely directed at me. You guys
want things to happen, make them happen!

Re: Tail pad optimization, cache friendlyness and C++ interrop


On Wednesday, 18 June 2014 at 06:50:14 UTC, deadalnix wrote:
That isn't splitting hair. You are loosing track of the big 
picture here. To come back to the original problem :


memset(&foo, 0, typeof(foo).sizeof);

Walter mention that this is not corrupting memory and therefore 
@safe.


memset is by definition an unsafe feature, but a hypothetical 
cleartype(foo,…) is a safe feature. Imagine having a hypothetical 
IR that makes the unsafe/safe distinction, then you can have both 
memset and cleartype in that IR and transform them into memset at 
the lower level backend without causing problems for memory 
safety verification.


In the situation of tail pad optimization, it is obviously not 
valid anymore and will cause memory corruption.


But if you have cleartype() when you do tail pad optimization and 
turn it into memset a codegen then you are ok?


The discussion then derailed to what is @safe, as the code is 
certainly @safe, but it is difficult to prove it is 
automatically) and the fact that @safe is defined backward (ie 
by listing what is not allowed and adding to the list when new 
holes are discovered rather than listing what is allowed and 
adding to the list when some construct are proven to be @safe).


I don't disagree, I think the simplest thing to do is to have a 
hypothetical implied IR between the AST and the backend and 
accept safe features on that level.


I think people who care about @safe also will accept that some 
safe programs are rejected if it is easy to modify the code into 
something the compiler accepts. The compiler could even provide 
suggestions: ("consider using cleartype() over memset()" etc).

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/17/2014 11:50 PM, deadalnix wrote:

and the fact that @safe is defined backward (ie by listing what is not allowed 
and
adding to the list when new holes are discovered


https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe%2C%20&keywords_type=allwords&list_id=41168&query_format=advanced

Currently, there are zero bugzilla issues tagged with 'safe'. Please file 
bugzilla issues for which ones are discovered and tag them!

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-18 Thread deadalnix via Digitalmars-d


On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright wrote:

On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing 
what is not allowed and

adding to the list when new holes are discovered


https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe%2C%20&keywords_type=allwords&list_id=41168&query_format=advanced

Currently, there are zero bugzilla issues tagged with 'safe'. 
Please file bugzilla issues for which ones are discovered and 
tag them!


I don't even know what to answer to that. We are clearly talking 
past each other here, and I have no idea how to convey the 
message in a better way.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-17 Thread deadalnix via Digitalmars-d

On Wednesday, 18 June 2014 at 06:35:01 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 17 June 2014 at 22:44:00 UTC, Timon Gehr wrote:
As you know this will not single out _exactly_ the subset of 
programs which is memory safe which is the claim I was arguing 
against,


It will single out exactly the programs that are most certainly 
memory safe, and also single out those programs that have 
generated unsafe features (instructions). Whether those unsafe 
features sit in a basic block that will never called is a 
different matter since @safe does not address that.


So yes, @safe is not equivalent to memory safety, it is 
equivalent to the absence of FEATURES that can lead to 
situations that aren't memory safe. But that is splitting hairs.




That isn't splitting hair. You are loosing track of the big 
picture here. To come back to the original problem :


memset(&foo, 0, typeof(foo).sizeof);

Walter mention that this is not corrupting memory and therefore 
@safe. In the situation of tail pad optimization, it is obviously 
not valid anymore and will cause memory corruption. The 
discussion then derailed to what is @safe, as the code is 
certainly @safe, but it is difficult to prove it is 
automatically) and the fact that @safe is defined backward (ie by 
listing what is not allowed and adding to the list when new holes 
are discovered rather than listing what is allowed and adding to 
the list when some construct are proven to be @safe).

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-17 Thread via Digitalmars-d


On Tuesday, 17 June 2014 at 22:44:00 UTC, Timon Gehr wrote:
As you know this will not single out _exactly_ the subset of 
programs which is memory safe which is the claim I was arguing 
against,


It will single out exactly the programs that are most certainly 
memory safe, and also single out those programs that have 
generated unsafe features (instructions). Whether those unsafe 
features sit in a basic block that will never called is a 
different matter since @safe does not address that.


So yes, @safe is not equivalent to memory safety, it is 
equivalent to the absence of FEATURES that can lead to situations 
that aren't memory safe. But that is splitting hairs.


Absence of features such as unsafe instructions is a trivial 
property of the compiled program. A non trivial property is 
whether the program terminates, returns 0, rejects the input 
"hello", etc.


and invoking Rice's theorem to this end is perfectly fine and 
does not suffer from any 'issues'.


Not really, you can prove termination for all programs with 3 
instructions and 3 bytes of RAM. You can do it for all programs 
with 4 instructions and 4 bytes of RAM. You can do it for all 
programs with N instructions and N bytes of RAM. You cannot do it 
for all TMs since they have unbounded storage.


Thus you can prove non-trivial properties such as whether a 
functions returns with 1, whether it accepts or rejects the input 
'0', etc. It might take a lot of time, but you can do it in a 
fixed amount of time. You cannot do it for TMs.


But this issue is simpler than that. Think about it this way: 
There are problems that have a solution, but it is provable 
impossible to solve analytically. You still can solve them 
numerically down to a specified precision.


I posit you can do the same with memory safety, as in: you can 
reject all unsafe programs and reduce the set of false positives 
to a marginal set of typical programs (which are written with 
memory safety in mind).

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-17 Thread Timon Gehr via Digitalmars-d

On 06/17/2014 11:50 PM, "Ola Fosheim Grøstad" 
" wrote:

...
Btw, Rice's theorem is based on the halting problem for TMs… so it
suffers from the same issues as everything else in theoretical CS when
it comes to practical situations.


There is no such 'issue', or any meaningful way to define a 'practical' 
situation, especially such that the definition would apply to the 
current context. Theoretical computer scientists are saying what they 
are saying and they know what they are saying.



Whether generated IR contains unsafe
instructions is trivially decidable. Since you can define an IR in a way
that discriminate between unsafe/safe instructions you can also decide
that the safe subset is verifiable memory safe.


As you know this will not single out _exactly_ the subset of programs 
which is memory safe which is the claim I was arguing against, and 
invoking Rice's theorem to this end is perfectly fine and does not 
suffer from any 'issues'. The kind of thing you discuss in this 
paragraph, which you appear to consider 'practical' is also studied in 
theoretical CS, so what's your point?

Re: Tail pad optimization, cache friendlyness and C++ interrop

On 6/17/2014 2:50 PM, "Ola Fosheim Grøstad" 
" wrote:

Out of curiosity, what is "memory safety" defined to be?


http://en.wikipedia.org/wiki/Memory_safety



Does it include running out of stack?


Depends. If the stack has protection against stack overflow, then it is memory 
safe. If not, it is not memory safe. A guard page is an example of the former, 
but D's fibers suffer from the latter.




Then just define the undefined behaviour as yielding the integer result of a
unspecified black box function of the input. Integer overflow should yield the
same value for the same operands on all ALUs. I don't understand how this
relates to memory safety?


Exactly - offer an improved wording rather than just throwing up hands.

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/17/2014 1:59 PM, deadalnix wrote:

On Tuesday, 17 June 2014 at 20:50:01 UTC, Walter Bright wrote:

What plan of action do you propose?

Make everything @system


The default is @system.



unless they are proven @safe instead of
trying to plug the holes in the condom one by one and hope you
don't end up with 20 years of child support.


Instead of asserting there are unspecified holes, please identify them with 
bugzilla issues and connect them with the 'safe' keyword. Doing otherwise is 
useless and nothing will come of it.


Arguing that the spec is wrong without identifying specifically what is wrong 
and how it should be corrected is useless and nothing will come of it.



There are many people (particularly Kenji) who spend many hours combing bugzilla 
looking for things to fix. Issues not in bugzilla do not get fixed. Nonspecific 
complaints on the n.g. are ineffective in garnering improvement.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-17 Thread via Digitalmars-d


On Monday, 16 June 2014 at 13:12:33 UTC, Timon Gehr wrote:
My point was that no implementation of @safe whatsoever can 
make it _equivalent_ to memory safety (i.e. @safe will never 
single out precisely those programs that do not corrupt 
memory). It will always only approximate memory safety. This is 
not a bug, it's just a fact.


Out of curiosity, what is "memory safety" defined to be? Does it 
include running out of stack?


It should not be a problem if @safe rejects some memory safe 
programs. It still verifies that they are memory safe if they 
pass (as opposed to "if and only if"). You can verify subsets 
even if you cannot define two crisp set that discriminate between 
all possible programs.


Btw, Rice's theorem is based on the halting problem for TMs… so 
it suffers from the same issues as everything else in theoretical 
CS when it comes to practical situations. Whether generated IR 
contains unsafe instructions is trivially decidable. Since you 
can define an IR in a way that discriminate between unsafe/safe 
instructions you can also decide that the safe subset is 
verifiable memory safe.


to agree on. In this case this is witnessed by the fact that 
you do not seem to want to ban undefined behaviour from @safe 
code which I can't agree with.


Then just define the undefined behaviour as yielding the integer 
result of a unspecified black box function of the input. Integer 
overflow should yield the same value for the same operands on all 
ALUs. I don't understand how this relates to memory safety?

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-17 Thread deadalnix via Digitalmars-d


On Tuesday, 17 June 2014 at 20:50:01 UTC, Walter Bright wrote:

On 6/17/2014 1:30 PM, deadalnix wrote:

I don't think he will. He's been explaining you for the past
several posts that this process is fundamentally broken, and
won't achieve the goals of @safe.

Please have a step back and look at the broader issue here.


What plan of action do you propose?


Make everything @system unless they are proven @safe instead of
trying to plug the holes in the condom one by one and hope you
don't end up with 20 years of child support.

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/17/2014 1:30 PM, deadalnix wrote:

I don't think he will. He's been explaining you for the past
several posts that this process is fundamentally broken, and
won't achieve the goals of @safe.

Please have a step back and look at the broader issue here.


What plan of action do you propose?

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-17 Thread deadalnix via Digitalmars-d


On Tuesday, 17 June 2014 at 20:25:52 UTC, Walter Bright wrote:

You have a lot of good thoughts on this issue.

You have specific problems in mind but do not identify them 
other than in vague terms. I guarantee that I am really, really 
bad at mindreading.


Instead, I would strongly prefer that you:

1. write bugzilla issues for the problems that you identify

2. connect those bugzilla issues regarding @safe with the 
'safe' keyword


3. construct specific proposals for how to fix these issues. 
The proposals don't actually have to be pull requests, just 
descriptions on the bugzilla pages for how to fix.


4. write pull requests for the documentation


Even doing just one of 1..4 would be most appreciated. Merely 
asserting that @safe is broken/buggy/etc. will not result in 
progress.


I don't think he will. He's been explaining you for the past
several posts that this process is fundamentally broken, and
won't achieve the goals of @safe.

Please have a step back and look at the broader issue here.

Re: Tail pad optimization, cache friendlyness and C++ interrop


You have a lot of good thoughts on this issue.

You have specific problems in mind but do not identify them other than in vague 
terms. I guarantee that I am really, really bad at mindreading.


Instead, I would strongly prefer that you:

1. write bugzilla issues for the problems that you identify

2. connect those bugzilla issues regarding @safe with the 'safe' keyword

3. construct specific proposals for how to fix these issues. The proposals don't 
actually have to be pull requests, just descriptions on the bugzilla pages for 
how to fix.


4. write pull requests for the documentation


Even doing just one of 1..4 would be most appreciated. Merely asserting that 
@safe is broken/buggy/etc. will not result in progress.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-16 Thread Timon Gehr via Digitalmars-d


On 06/16/2014 06:49 AM, Walter Bright wrote:

On 6/15/2014 4:26 PM, Timon Gehr wrote:

On 06/16/2014 01:06 AM, Walter Bright wrote:

I don't understand your question. I don't know what is unhelpful about
saying that @safe refers to memory safety.
...


You stated the two to be equivalent earlier, which is impossible.


It is for Java,


No. sun.misc.Unsafe can be used to write memory safe code.


why should D be different?



The list is not restricted to syntactic issues.

(Yes it is,


No, it is not. For example, assigning an int to a pointer is a semantic
issue, not a [syntactic] one.
...


By extension, memory safety is a semantic issue. Since it is 
non-trivial, it is in general not verifiable. (This is Rice's Theorem.)


@safe-ty OTOH is a verifiable property of the program.


...


I'm just trying to find the definition/theorem we do not agree on.


I strongly suggest that you can help by identifying specific issues in
bugzilla


My point was that no implementation of @safe whatsoever can make it 
_equivalent_ to memory safety (i.e. @safe will never single out 
precisely those programs that do not corrupt memory). It will always 
only approximate memory safety. This is not a bug, it's just a fact.



and marking them with the 'safe' keyword, as I suggested
earlier.


In my book, the main problem is that @safe is not specified in a way 
that is easy to be verified to guarantee memory safety. I think plugging 
holes one after another as they are discovered in real code  until 
_hopefully_ none remain is not a very productive use of time. We should 
strive to keep @safe sound during its whole implementation.



I do not believe that memory safety is a difficult concept to
agree on.



Why? Many superficially simple informal concepts are difficult to agree 
on. In this case this is witnessed by the fact that you do not seem to 
want to ban undefined behaviour from @safe code which I can't agree with.

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/15/2014 9:49 PM, Walter Bright wrote:

No, it is not. For example, assigning an int to a pointer is a semantic issue,
not a semantic one.


Gack, I meant "not a SYNTACTIC one".

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/15/2014 4:26 PM, Timon Gehr wrote:

On 06/16/2014 01:06 AM, Walter Bright wrote:

I don't understand your question. I don't know what is unhelpful about
saying that @safe refers to memory safety.
...


You stated the two to be equivalent earlier, which is impossible.


It is for Java, why should D be different?



The list is not restricted to syntactic issues.

(Yes it is,


No, it is not. For example, assigning an int to a pointer is a semantic issue, 
not a semantic one.




but that is not important because here the problem here is clearly
that these terms have wildly different meanings in different communities.)


I don't think the distinction is hard to grasp.



I'm just trying to find the definition/theorem we do not agree on.


I strongly suggest that you can help by identifying specific issues in bugzilla 
and marking them with the 'safe' keyword, as I suggested earlier. I do not 
believe that memory safety is a difficult concept to agree on.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-15 Thread Timon Gehr via Digitalmars-d


On 06/16/2014 01:06 AM, Walter Bright wrote:

On 6/15/2014 3:45 PM, Timon Gehr wrote:

I don't know why the documentation says that. D's @safe is about memory
safety, not undefined behavior.
...


Note that this is frustratingly unhelpful for deciphering your point
about
"memory safe" <=> "verifiably @safe" by definition. Are you defining
"memory
safe" or "verifiably @safe"?


I don't understand your question. I don't know what is unhelpful about
saying that @safe refers to memory safety.
...


You stated the two to be equivalent earlier, which is impossible.




Note that the list of eschewed behaviors are possibly memory corrupting.


It is an incomplete list.


I ask that you enumerate the missing items, put the list in bugzilla,
and tag them with the 'safe' keyword.



In any case, I
don't see how any list of (syntactic) verifiable properties of the
code is
supposed to be equivalent to the (non-trivial semantic) memory safety
property.


The list is not restricted to syntactic issues.
...


(Yes it is, but that is not important because here the problem here is 
clearly that these terms have wildly different meanings in different 
communities.)


The important distinction is between verifiable and non-verifiable. 
@safe cannot be equivalent to memory safe because @safe is verifiable 
and memory safe is not.





Are you assuming @trusted as an oracle for memory safety and saying
@trusted
code is 'verifiably @safe' code? (That's not the intended reading.)


Not at all. Where does the spec suggest that?
...


I'm just trying to find the definition/theorem we do not agree on.




Signed integer overflow, for example, is not listed.

Are you trying to say that signed integer overflow is undefined
behaviour in D?
(This would again contradict the documentation.)


I know the spec says it follows 2's complement arithmetic. I'm not 100%
confident we can rely on that for all 2's complement CPUs, and
furthermore we have a bit of a problem in relying on optimizers built
for C/C++ which rely on it being undefined behavior.

In any case, it is still not an issue for @safe.


Maybe not in practice (though I'll not bet on it), but a conforming 
implementation can do _anything at all_ if undefined behaviour occurs, 
including behaving as if memory had been corrupted.

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/15/2014 3:45 PM, Timon Gehr wrote:

I don't know why the documentation says that. D's @safe is about memory
safety, not undefined behavior.
...


Note that this is frustratingly unhelpful for deciphering your point about
"memory safe" <=> "verifiably @safe" by definition. Are you defining "memory
safe" or "verifiably @safe"?


I don't understand your question. I don't know what is unhelpful about saying 
that @safe refers to memory safety.




Note that the list of eschewed behaviors are possibly memory corrupting.


It is an incomplete list.


I ask that you enumerate the missing items, put the list in bugzilla, and tag 
them with the 'safe' keyword.




In any case, I
don't see how any list of (syntactic) verifiable properties of the code is
supposed to be equivalent to the (non-trivial semantic) memory safety property.


The list is not restricted to syntactic issues.



Are you assuming @trusted as an oracle for memory safety and saying @trusted
code is 'verifiably @safe' code? (That's not the intended reading.)


Not at all. Where does the spec suggest that?



Signed integer overflow, for example, is not listed.

Are you trying to say that signed integer overflow is undefined behaviour in D?
(This would again contradict the documentation.)


I know the spec says it follows 2's complement arithmetic. I'm not 100% 
confident we can rely on that for all 2's complement CPUs, and furthermore we 
have a bit of a problem in relying on optimizers built for C/C++ which rely on 
it being undefined behavior.


In any case, it is still not an issue for @safe.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-15 Thread Timon Gehr via Digitalmars-d


On 06/15/2014 08:44 PM, Walter Bright wrote:

On 6/15/2014 2:48 AM, Timon Gehr wrote:

On 06/15/2014 10:33 AM, Walter Bright wrote:


What Timon is saying is that not all memory safe code is verifiably
@safe.


In D, they are defined to be the same thing,


Since when?

http://dlang.org/function
 ...


so the statement makes no sense.


Then please indicate how to fix the documentation. If you are going to
claim the
Humpty Dumpty privilege, I'll back off. Thanks.



I don't know why the documentation says that. D's @safe is about memory
safety, not undefined behavior.
...


Note that this is frustratingly unhelpful for deciphering your point 
about "memory safe" <=> "verifiably @safe" by definition. Are you 
defining "memory safe" or "verifiably @safe"?



Note that the list of eschewed behaviors are possibly memory corrupting.


It is an incomplete list. I'd rather see an incomplete list of _allowed_ 
behaviours instead of an incomplete list of eschewed behaviours. In any 
case, I don't see how any list of (syntactic) verifiable properties of 
the code is supposed to be equivalent to the (non-trivial semantic) 
memory safety property. Are you assuming @trusted as an oracle for 
memory safety and saying @trusted code is 'verifiably @safe' code? 
(That's not the intended reading.)



Signed integer overflow, for example, is not listed.



Are you trying to say that signed integer overflow is undefined 
behaviour in D?  (This would again contradict the documentation.)

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/15/2014 2:30 AM, Maxim Fomin wrote:

I found dozens of cases when @safe is broken, let alone other issues in
bugzilla.


I have added the keyword 'safe' to bugzilla. I'd appreciate it if you would go 
through the bugzilla issues you've identified with @safe, and mark them with the 
'safe' keyword.


Thanks!

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/15/2014 2:30 AM, Maxim Fomin wrote:

On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote:

On 6/11/2014 4:34 AM, Timon Gehr wrote:

Not memory safe implies (is supposed to imply) not @safe but not @safe does not
imply not memory safe.


@safe in D == memory safe.


Why? I found dozens of cases when @safe is broken, let alone other issues in
bugzilla.


Those are bugs. We aim to fix them.



By the way, memory safety is also compromised by compiler bugs which make him
generate buggy code. Note, when I counted memory safety problems, codegen issues
were not counted.


I don't think we should mix intention with bugs. Bugs need to get fixed.



I have reached this conclusion some years ago and nothing has change in D since
then which make me reconsidering my opinion (including that @safe holes were not
fixed).


I do welcome help in fixing bugs.

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/15/2014 2:48 AM, Timon Gehr wrote:

On 06/15/2014 10:33 AM, Walter Bright wrote:


What Timon is saying is that not all memory safe code is verifiably
@safe.


In D, they are defined to be the same thing,


Since when?

http://dlang.org/function

"Function Safety

Safe functions are functions that are _statically checked_ to exhibit _no
possibility of undefined behavior_. Undefined behavior is often used as a vector
for malicious attacks.

Safe Functions

Safe functions are marked with the @safe attribute.

The following operations are not allowed in safe functions:"

I.e. the documentation has two (conflicting) definitions and none of them is the
one you claim there is.


so the statement makes no sense.


Then please indicate how to fix the documentation. If you are going to claim the
Humpty Dumpty privilege, I'll back off. Thanks.



I don't know why the documentation says that. D's @safe is about memory safety, 
not undefined behavior.


Note that the list of eschewed behaviors are possibly memory corrupting. Signed 
integer overflow, for example, is not listed.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-15 Thread Timon Gehr via Digitalmars-d


On 06/15/2014 10:33 AM, Walter Bright wrote:


What Timon is saying is that not all memory safe code is verifiably
@safe.


In D, they are defined to be the same thing,


Since when?

http://dlang.org/function

"Function Safety

Safe functions are functions that are _statically checked_ to exhibit 
_no possibility of undefined behavior_. Undefined behavior is often used 
as a vector for malicious attacks.


Safe Functions

Safe functions are marked with the @safe attribute.

The following operations are not allowed in safe functions:"

I.e. the documentation has two (conflicting) definitions and none of 
them is the one you claim there is.



so the statement makes no sense.


Then please indicate how to fix the documentation. If you are going to 
claim the Humpty Dumpty privilege, I'll back off. Thanks.


On 06/11/2014 11:35 AM, Walter Bright wrote:

What's not provable? Why would bit copying a struct not be memory safe?


Since you claim memory safe is the same as verifiably @safe, you are asking:


What's not provable? Why would bit copying a struct not be verifiably @safe?


struct S{ int x; }

void main()@safe{
S s,t;
memcpy(&s,&t,S.sizeof); // error
}

So, what is it that you are trying to bring across?

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-15 Thread Maxim Fomin via Digitalmars-d


On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote:

On 6/11/2014 4:34 AM, Timon Gehr wrote:
Not memory safe implies (is supposed to imply) not @safe but 
not @safe does not

imply not memory safe.


@safe in D == memory safe.


Why? I found dozens of cases when @safe is broken, let alone 
other issues in bugzilla.


After thinking about the @safety in D my conclusion is that it is 
impossible to evaluate memory and safety correctness of a code in 
which static type says nothing about where an object is 
allocated. Contrary to popular wisdom, one can have fixed array 
on heaps, classes on stack, etc. If any code which is potentially 
not safe is rejected, this would lead to lots of false positives 
making using the language very inconvenient. Even in that case, 
safety cannot be guaranteed by the language due to other issues, 
like separate compilation, etc. By the way, memory safety is also 
compromised by compiler bugs which make him generate buggy code. 
Note, when I counted memory safety problems, codegen issues were 
not counted.


@safe should not be considered as feature which ensures that the 
code is memory safe, but as a feature rejecting code with high 
probability of memory bugs. The difference is very important.


I have reached this conclusion some years ago and nothing has 
change in D since then which make me reconsidering my opinion 
(including that @safe holes were not fixed).


Note, that I do not critique the language, it is fine. It is very 
good system level language with powerful modelling features. It 
is not good at verifying memory correctness, because in such 
languages (unlike managed ones) burden of memory correctness lies 
mostly on programmer. If he thinks that he can outsource memory 
correctness to @safe, there is high probability that he would be 
suddenly surprised.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-15 Thread bearophile via Digitalmars-d


David Nadlinger:


@safe => memory safe, but not memory safe => @safe.


Apparently that's not true, according to the post on the LLVM 
blog linked here:

http://forum.dlang.org/thread/okratgxrikskmylmw...@forum.dlang.org

Bye,
bearophile

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/15/2014 12:44 AM, David Nadlinger wrote:

On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote:

On 6/11/2014 4:34 AM, Timon Gehr wrote:

Not memory safe implies (is supposed to imply) not @safe but not @safe does not
imply not memory safe.


@safe in D == memory safe.


What Timon is saying is that not all memory safe code is verifiably @safe.


In D, they are defined to be the same thing, so the statement makes no sense.



@safe => memory safe, but not memory safe => @safe.

David

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-15 Thread David Nadlinger via Digitalmars-d


On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote:

On 6/11/2014 4:34 AM, Timon Gehr wrote:
Not memory safe implies (is supposed to imply) not @safe but 
not @safe does not

imply not memory safe.


@safe in D == memory safe.


What Timon is saying is that not all memory safe code is 
verifiably @safe.


@safe => memory safe, but not memory safe => @safe.

David

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-14 Thread Sean Cavanaugh via Digitalmars-d


On 6/11/2014 8:56 AM, Remo wrote:


This is pretty strange behavior.
At least on Windows I can not confirm this.
Visual Studio 2013, Intel Compiler and Clang for windows have the same
consistent behavior here.

private  do NOT affect struct size.

But there is a parameter in Visual Studio that will affect it called
"Struct Member Alignment"
http://msdn.microsoft.com/en-us/library/xh3e3fd0.aspx

1 Byte (/Zp1)  sizeof(S1)=5,  sizeof(S2)=6
2 Byte (/Zp2)  sizeof(S1)=6,  sizeof(S2)=8
4 Byte (/Zp4)  sizeof(S1)=8,  sizeof(S2)=12
8 Byte (/Zp8)  sizeof(S1)=8,  sizeof(S2)=12   this is the default.

Of course the same can be done with #pragma pack(?) .

There is also __declspec(align(?)) and in C++11  alignas(?) but its
behavior is different from #pragma pack(?) .




For inheritance I've seen gcc and clang allow the inheriting to go into 
the tail padding of the previous class in the hierarchy, technically 
legal but always gives me scary thoughts before going to sleep at night.


MSVC pads up the classes to the alignment size and inheritance starts 
from there, a bit wasteful but far safer.


struct foo  { int x; char y; };
struct bar : public foo { char z; }

sizeof(foo == 8);
sizeof(bar == 8); // clang and gcc on linux
sizeof(bar == 12); // msvc

The windows case is generally safer as memset(&class, 0, sizeof(class)) 
won't clobber inherited members, but its also not supposed to be legal 
to do things like memsetting anything that fails is_pod etc in c++, 
however since nearly all code I've worked with has constructors is_pod 
is useless and people just memset struct-like objects without a care int 
he world, which can be fun when porting :)

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-11 Thread Walter Bright via Digitalmars-d


On 6/11/2014 4:34 AM, Timon Gehr wrote:

Not memory safe implies (is supposed to imply) not @safe but not @safe does not
imply not memory safe.


@safe in D == memory safe.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-11 Thread Remo via Digitalmars-d


On Wednesday, 11 June 2014 at 07:22:51 UTC, deadalnix wrote:

On Wednesday, 11 June 2014 at 06:30:26 UTC, Walter Bright wrote:

On 6/10/2014 11:11 PM, deadalnix wrote:
On Wednesday, 11 June 2014 at 04:11:53 UTC, Walter Bright 
wrote:

Hmm, this could have serious problems with the following:

S1 s1;
S2 s2;
s2.c = 3;
memcpy(&s2.s1, &s1, sizeof(S1)); // Oops! stomped on s2.c


Yes, that is why they do it only in specific condition (ie 
when the thing use

C++ specific feature and not C one).


I don't understand - didn't you say this was expressible as C 
structs? Aren't those supposed to be compatible with C?





struct S1 {
int a;
private:
char b;
};

struct S2 : S1 {
char c;
};

S2 is 8 bytes. If you remove private in S1, then S2 becomes 12 
bytes. S1 is not a "C" struct anymore and do not need to follow 
the standard layout.


This is pretty strange behavior.
At least on Windows I can not confirm this.
Visual Studio 2013, Intel Compiler and Clang for windows have the 
same consistent behavior here.


private  do NOT affect struct size.

But there is a parameter in Visual Studio that will affect it 
called "Struct Member Alignment"

http://msdn.microsoft.com/en-us/library/xh3e3fd0.aspx

1 Byte (/Zp1)  sizeof(S1)=5,  sizeof(S2)=6
2 Byte (/Zp2)  sizeof(S1)=6,  sizeof(S2)=8
4 Byte (/Zp4)  sizeof(S1)=8,  sizeof(S2)=12
8 Byte (/Zp8)  sizeof(S1)=8,  sizeof(S2)=12   this is the default.

Of course the same can be done with #pragma pack(?) .

There is also __declspec(align(?)) and in C++11  alignas(?) but 
its behavior is different from #pragma pack(?) .

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-11 Thread Timon Gehr via Digitalmars-d


On 06/11/2014 11:35 AM, Walter Bright wrote:


I'm not so sure about that, either. There are many ways of bit copying
structs, and some of them are perfectly memory safe.



It is not provable by the compiler, therefore it is not @safe.


Not memory safe implies (is supposed to imply) not @safe but not @safe 
does not imply not memory safe.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-11 Thread Walter Bright via Digitalmars-d


On 6/11/2014 12:22 AM, deadalnix wrote:

On Wednesday, 11 June 2014 at 06:30:26 UTC, Walter Bright wrote:

On 6/10/2014 11:11 PM, deadalnix wrote:

On Wednesday, 11 June 2014 at 04:11:53 UTC, Walter Bright wrote:

Hmm, this could have serious problems with the following:

S1 s1;
S2 s2;
s2.c = 3;
memcpy(&s2.s1, &s1, sizeof(S1)); // Oops! stomped on s2.c


Yes, that is why they do it only in specific condition (ie when the thing use
C++ specific feature and not C one).


I don't understand - didn't you say this was expressible as C structs? Aren't
those supposed to be compatible with C?




struct S1 {
 int a;
private:
 char b;
};

struct S2 : S1 {
 char c;
};

S2 is 8 bytes. If you remove private in S1, then S2 becomes 12 bytes. S1 is not
a "C" struct anymore and do not need to follow the standard layout.


Ok, I understand that, but I'd find it surprising behavior that a protection 
attribute affected layout.




and certainly not in @safe D.


I'm not so sure about that, either. There are many ways of bit copying
structs, and some of them are perfectly memory safe.



It is not provable by the compiler, therefore it is not @safe.


What's not provable? Why would bit copying a struct not be memory safe?



The fundamental problem with this optimization is now a struct has two sizes -
the unpadded and the padded size. I foresee nothing but problems, corner
cases, and bugs inherent in trying to select which size to use for which
purpose. I do not understand how C++ avoids these issues.


By not spilling out for struct that do not have standard layout. In above
example, the compiler won't issue code that manipulate the padding after S1 as
it may contains something.


Ok, I can see that, but forcing memberwise copy has its own efficiency problems, 
especially when doing things like enregistering it.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-11 Thread deadalnix via Digitalmars-d


On Wednesday, 11 June 2014 at 06:30:26 UTC, Walter Bright wrote:

On 6/10/2014 11:11 PM, deadalnix wrote:
On Wednesday, 11 June 2014 at 04:11:53 UTC, Walter Bright 
wrote:

Hmm, this could have serious problems with the following:

S1 s1;
S2 s2;
s2.c = 3;
memcpy(&s2.s1, &s1, sizeof(S1)); // Oops! stomped on s2.c


Yes, that is why they do it only in specific condition (ie 
when the thing use

C++ specific feature and not C one).


I don't understand - didn't you say this was expressible as C 
structs? Aren't those supposed to be compatible with C?





struct S1 {
int a;
private:
char b;
};

struct S2 : S1 {
char c;
};

S2 is 8 bytes. If you remove private in S1, then S2 becomes 12 
bytes. S1 is not a "C" struct anymore and do not need to follow 
the standard layout.



and certainly not in @safe D.


I'm not so sure about that, either. There are many ways of bit 
copying structs, and some of them are perfectly memory safe.




It is not provable by the compiler, therefore it is not @safe.

The fundamental problem with this optimization is now a struct 
has two sizes - the unpadded and the padded size. I foresee 
nothing but problems, corner cases, and bugs inherent in trying 
to select which size to use for which purpose. I do not 
understand how C++ avoids these issues.


By not spilling out for struct that do not have standard layout. 
In above example, the compiler won't issue code that manipulate 
the padding after S1 as it may contains something.

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/10/2014 11:11 PM, deadalnix wrote:

On Wednesday, 11 June 2014 at 04:11:53 UTC, Walter Bright wrote:

Hmm, this could have serious problems with the following:

S1 s1;
S2 s2;
s2.c = 3;
memcpy(&s2.s1, &s1, sizeof(S1)); // Oops! stomped on s2.c


Yes, that is why they do it only in specific condition (ie when the thing use
C++ specific feature and not C one).


I don't understand - didn't you say this was expressible as C structs? Aren't 
those supposed to be compatible with C?




This kind of thing is valid in C, but isn't
supposed to be in C++,


I'm not so sure about that.


and certainly not in @safe D.


I'm not so sure about that, either. There are many ways of bit copying structs, 
and some of them are perfectly memory safe.


The fundamental problem with this optimization is now a struct has two sizes - 
the unpadded and the padded size. I foresee nothing but problems, corner cases, 
and bugs inherent in trying to select which size to use for which purpose. I do 
not understand how C++ avoids these issues.

Re: Tail pad optimization, cache friendlyness and C++ interrop


On Wednesday, 11 June 2014 at 04:11:53 UTC, Walter Bright wrote:

Hmm, this could have serious problems with the following:

S1 s1;
S2 s2;
s2.c = 3;
memcpy(&s2.s1, &s1, sizeof(S1)); // Oops! stomped on s2.c


Yes, that is why they do it only in specific condition (ie when 
the thing use C++ specific feature and not C one). This kind of 
thing is valid in C, but isn't supposed to be in C++, and 
certainly not in @safe D.

Re: Tail pad optimization, cache friendlyness and C++ interrop


On Wednesday, 11 June 2014 at 03:19:55 UTC, Walter Bright wrote:

On 6/10/2014 7:44 PM, deadalnix wrote:
On Wednesday, 11 June 2014 at 02:10:18 UTC, Walter Bright 
wrote:

On 6/10/2014 5:27 PM, deadalnix wrote:

I'm talking about structs, not classes.


Ok, but since D structs do not inherit, how does tail pad 
optimization apply?


struct S1 {
 int a;
 byte b;
}

struct S2 {
 S1 s1;
 char c;
}

Sé could be 8 byte long (some variation of this are in C++ for
instance if I make a public and b private).


Do any C++ compilers do this for this case, or just for the 
inheritance one?


They do it in the condition mentioned for extern(C++) in my first 
post (at least clang and gcc, C++ ABI isn't well defined, so 
other compiler may do thing differently).

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/10/2014 7:44 PM, deadalnix wrote:

On Wednesday, 11 June 2014 at 02:10:18 UTC, Walter Bright wrote:

On 6/10/2014 5:27 PM, deadalnix wrote:

I'm talking about structs, not classes.


Ok, but since D structs do not inherit, how does tail pad optimization apply?


struct S1 {
  int a;
  byte b;
}

struct S2 {
  S1 s1;
  char c;
}


Hmm, this could have serious problems with the following:

S1 s1;
S2 s2;
s2.c = 3;
memcpy(&s2.s1, &s1, sizeof(S1)); // Oops! stomped on s2.c

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/10/2014 7:44 PM, deadalnix wrote:

On Wednesday, 11 June 2014 at 02:10:18 UTC, Walter Bright wrote:

On 6/10/2014 5:27 PM, deadalnix wrote:

I'm talking about structs, not classes.


Ok, but since D structs do not inherit, how does tail pad optimization apply?


struct S1 {
  int a;
  byte b;
}

struct S2 {
  S1 s1;
  char c;
}

Sé could be 8 byte long (some variation of this are in C++ for
instance if I make a public and b private).


Do any C++ compilers do this for this case, or just for the inheritance one?

Re: Tail pad optimization, cache friendlyness and C++ interrop


On Wednesday, 11 June 2014 at 02:10:18 UTC, Walter Bright wrote:

On 6/10/2014 5:27 PM, deadalnix wrote:

I'm talking about structs, not classes.


Ok, but since D structs do not inherit, how does tail pad 
optimization apply?


struct S1 {
 int a;
 byte b;
}

struct S2 {
 S1 s1;
 char c;
}

Sé could be 8 byte long (some variation of this are in C++ for
instance if I make a public and b private).

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/10/2014 5:27 PM, deadalnix wrote:

I'm talking about structs, not classes.


Ok, but since D structs do not inherit, how does tail pad optimization apply?

Re: Tail pad optimization, cache friendlyness and C++ interrop


On Tuesday, 10 June 2014 at 20:50:46 UTC, Walter Bright wrote:

On 6/10/2014 12:30 AM, deadalnix wrote:

thought ?


This does not apply to D structs because D structs do not 
inherit.


C doesn't have classes, so no issues there.

extern(C++) class should match the C++ ABI for this.

extern(D) class we are free to innovate with the layout.

I suggest turning this into a bugzilla enhancement request.


I'm talking about structs, not classes.

Re: Tail pad optimization, cache friendlyness and C++ interrop


On 6/10/2014 12:30 AM, deadalnix wrote:

thought ?


This does not apply to D structs because D structs do not inherit.

C doesn't have classes, so no issues there.

extern(C++) class should match the C++ ABI for this.

extern(D) class we are free to innovate with the layout.

I suggest turning this into a bugzilla enhancement request.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-10 Thread Dmitry Olshansky via Digitalmars-d


10-Jun-2014 11:30, deadalnix пишет:
[snip]

extern(D) do tail pad optimize.
extern(C) struct do not tail pad optimize.
extern(C++) do tail pad with C++ rules:
do not tail pad if (otherwise tail pad):
1. has no non-static data members that aren't standard-layout
2. has no virtual functions and no virtual base classes
3. has the same access control for all non-static data members
4. has no base classes that aren't standard-layout
5. either has no base class with non-static data members or has no
non-static data members in the most derived class and only one base with
them
6. has no base classes of the same type as the first non-static data member

thought ?


Would be useful, but as proposed it might break some of current C 
bindings silently (unless it's extern(C): at the top of file).



--
Dmitry Olshansky

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-10 Thread via Digitalmars-d


On Tuesday, 10 June 2014 at 08:57:26 UTC, bearophile wrote:

deadalnix:


thought ?


I think for D there is a lower handing fruit: the D specs allow 
to reorder class instance fields, but I think the D front-end 
is not yet doing that.


But only for classes, not for structs.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-10 Thread bearophile via Digitalmars-d


deadalnix:


thought ?


I think for D there is a lower handing fruit: the D specs allow 
to reorder class instance fields, but I think the D front-end is 
not yet doing that.


Bye,
bearophile

Tail pad optimization, cache friendlyness and C++ interrop