View mode: basic / threaded / horizontal-split · Log in · Help
December 27, 2011
Re: Carmack about static analysis
On 12/26/2011 9:03 AM, Andrei Alexandrescu wrote:
> On 12/26/11 10:29 AM, deadalnix wrote:
>> Do you know what is the impact of 64bits on false positive proportion
>> when the GC isn't precise ?
>
> No.

I would think it would dramatically reduce it.
December 27, 2011
Re: Carmack about static analysis
On 12/26/11 6:36 PM, Walter Bright wrote:
> On 12/26/2011 9:03 AM, Andrei Alexandrescu wrote:
>> On 12/26/11 10:29 AM, deadalnix wrote:
>>> Do you know what is the impact of 64bits on false positive proportion
>>> when the GC isn't precise ?
>>
>> No.
>
> I would think it would dramatically reduce it.

At the same time, false positives are not the only reason for which 
precision is good. Precision reduces the amount of work done by the 
scanner, allows e.g. using distinct regions for objects with/without 
embedded pointers, and allows moving objects.

Andrei
December 27, 2011
Re: Carmack about static analysis
Walter Bright wrote:

>      bool notFeature;

Counterexample:

|       bool sense;

I do not believe, that a majority of developers evaluates `nonsense' as 
being equal to `!sense'.

-manfred
December 27, 2011
Re: Carmack about static analysis
Le 27/12/2011 02:07, Andrei Alexandrescu a écrit :
> On 12/26/11 6:36 PM, Walter Bright wrote:
>> On 12/26/2011 9:03 AM, Andrei Alexandrescu wrote:
>>> On 12/26/11 10:29 AM, deadalnix wrote:
>>>> Do you know what is the impact of 64bits on false positive proportion
>>>> when the GC isn't precise ?
>>>
>>> No.
>>
>> I would think it would dramatically reduce it.
>
> At the same time, false positives are not the only reason for which
> precision is good. Precision reduces the amount of work done by the
> scanner, allows e.g. using distinct regions for objects with/without
> embedded pointers, and allows moving objects.
>
> Andrei
>

Using different region for object that or may not contains pointers is 
something that can be achieved with the current state of D.

Agreed for everythign else.
December 27, 2011
Re: Carmack about static analysis
On 12/25/2011 10:23 PM, Andrei Alexandrescu wrote:
>
> As a first step, we must make all allocations except stack type-aware,
> and leave only the stack to be imprecise.
>

Couldn't the GC'ing the stack be handled in a similar style to how the 
Windows x64 ABI functions with respect to exception handling?

The unwinding code lives outside the normal program flow to reduce 
runtime overhead as much as posisble, at least until an exception is 
thrown.  At which point the exception handlers traverse this data 
structure to unwind the stack from wherever you are in your function 
(and its caller and so on).

I would imagine a GC system could do something very similar.  There are 
a few MSDN blogs with a bunch of useful links out to more detailed 
information:

http://blogs.msdn.com/b/freik/archive/2006/01/04/509372.aspx

http://blogs.msdn.com/b/freik/archive/2005/03/17/398200.aspx

http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx
December 27, 2011
Re: Carmack about static analysis
On 2011-12-26 21:55, Walter Bright wrote:
> On 12/26/2011 3:47 AM, Jacob Carlborg wrote:
>> It's like when you see code like this (Ruby):
>>
>> unless !foo
>>
>> end
>>
>> Double negation. Code like the snippet above can be really annoying.
>
> In general, variables and conditions should never be labeled with negation:
>
> bool notFeature;

I agree.

-- 
/Jacob Carlborg
December 27, 2011
Re: Carmack about static analysis
On 2011-12-27 00:23, Robert Jacques wrote:
> On Mon, 26 Dec 2011 07:43:46 -0800, Jacob Carlborg <doob@me.com> wrote:
>> On 2011-12-26 15:52, Andrei Alexandrescu wrote:
>>> On 12/26/11 6:53 AM, Jacob Carlborg wrote:
>>>> What about the parallel/concurrent collector that has been linked a
>>>> couple of times in this newsgroup. Would that be possible and a good
>>>> idea to implement?
>>>
>>> A parallel collector would be, of course, a valuable addition.
>>>
>>> Andrei
>>
>> This is the collector I was referring to:
>> http://www.artima.com/lejava/articles/azul_pauseless_gc.html
>
> The C4 pause-less GC, while very cool, is its own operating system. It
> doesn't run on-top of Windows, Linux, Mac, etc. CDGC, on the other hand,
> is a concurrent collector that only runs on *nixes. Thread-local GCs are
> a form of mostly parallel/concurrent collectors which are a good match
> for D, but requires our memory model to support/include regions. There
> has also been some work recently in making fully precise collectors for
> C, which would be directly applicable to D.

That's why I said if possible to implement.

-- 
/Jacob Carlborg
December 28, 2011
Re: Carmack about static analysis
On Tue, 27 Dec 2011 10:35:02 -0800, Sean Cavanaugh <WorksOnMyMachine@gmail.com> wrote:

> On 12/25/2011 10:23 PM, Andrei Alexandrescu wrote:
>>
>> As a first step, we must make all allocations except stack type-aware,
>> and leave only the stack to be imprecise.
>>
>
> Couldn't the GC'ing the stack be handled in a similar style to how the
> Windows x64 ABI functions with respect to exception handling?
>
> The unwinding code lives outside the normal program flow to reduce
> runtime overhead as much as posisble, at least until an exception is
> thrown.  At which point the exception handlers traverse this data
> structure to unwind the stack from wherever you are in your function
> (and its caller and so on).
>
> I would imagine a GC system could do something very similar.  There are
> a few MSDN blogs with a bunch of useful links out to more detailed
> information:
>
> http://blogs.msdn.com/b/freik/archive/2006/01/04/509372.aspx
>
> http://blogs.msdn.com/b/freik/archive/2005/03/17/398200.aspx
>
> http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx

Fully precise collectors for C have been done; e.g. MAGPIE: PRECISE GARBAGE COLLECTION FOR C
February 09, 2012
Re: Carmack about static analysis
On 24/12/2011 12:42, bearophile wrote:
> A new blog post by the very good John Carmack, I like how well readable this post is:
> http://altdevblogaday.com/2011/12/24/static-code-analysis/
>

Nice article! I particularly liked this comment:
"The classic hacker disdain for “bondage and discipline languages” is 
short sighted – the needs of large, long-lived, multi-programmer 
projects are just different than the quick work you do for yourself."
that throws a jab at a lot of the obsession with dynamic languages that 
goes on out there.
It's something I've echoed in the past, especially when people start 
comparing languages to one another using small code snippets, and 
picking on issues/advantages that actually are only significant when 
writing small sized code, but not at all for medium/large sized apps. 
(the Hello-World Snippet Fallacy?)


-- 
Bruno Medeiros - Software Engineer
February 09, 2012
Re: Carmack about static analysis
On 24/12/2011 23:27, Adam D. Ruppe wrote:
> On Saturday, 24 December 2011 at 23:12:27 UTC, bearophile wrote:
>> I was talking about the abundance of (({}){()}) and not about
>> identifiers length.
>
> It's the same fallacy. I can't read Carmack's mind, but
> I'm sure he's talking about shortening code the same way
> I would mean it if I said it - simpler concepts, fewer cases,
> less repetition.
>
> It's about how much you have to think about, now how much you
> have to read/write.

Exactly.
Reminds me of the issues that some people have with Java 
closures/lambdas. You do closures/lambdas in Java by means of creating 
an anonymous class and then implementing a method, and this is much more 
verbose than a plain lambda syntax, like D has (or many other functional 
languages). But although it is much more verbose, it is actually not 
that much more complex, it doesn't add much more to think about.
There is however another issue with Java's closures/lambdas which is not 
complained or mentioned as much as the above, but is actually much more 
annoying because it adds more semantic complexity: the closure can't 
modify (the immediate/head value of) the outer variables. So when 
modifying is necessary, you often see code where people instantiate a 
one element array, the closure accesses the array (the array reference 
is not modified), it then modifies the element inside, in index 0, and 
then that is retrieved by the outer code when the closure finishes. This 
on the other is a much more serious issue, and adds more complexity to 
the code beyond just verbosity.


-- 
Bruno Medeiros - Software Engineer
3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home