www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is const to ease programming or compiling multicore?

reply Georg Wrede <georg nospam.org> writes:
I'm not sure if the current way const is heading is for better (read, 
more productive, i.e. safer and /faster/ ) programming, or if it is for 
better compiler omtimizability in a multithread+multiprocessor setting, 
forgetting the poor programmer.

Of course, the holy grail would be getting both, but I'm not so sure 
that is even within reachability of D2. Maybe D3, though? In that case 
should we try to get there one step at a time? But then, where should we 
draw the line on how far we try to get with D2?

---

Im' not familar with, so does anybody know of any texts available on 
statistical properties of existing major codebases? Like how often does 
a variable get reassigned more than once in a program, or how often does 
a reference or a pointer get reassigned, with or without regard to if 
data has been changed via it.

And if such data (or academic papers) don't exist, then MIT and others 
sure as hell should start looking into it. There's enough source code 
for C and C++ on any Linux source distribution dvd, for Java there's at 
least OpenOffice source, and Python and other languages also are 
options.  And some of the lessons learned most probably go for the whole 
spread of "our sister" languages as such.

---

Thinking about this also gives some ideas. Like, suppose "a C like 
language" decides to skip const altogether, and instead rely on the 
compiler simply checking whether a variable is assigned to once, or more 
than once in the code. This might even be as simple as grepping for 
assignments to the variable(1). And if it turns out it's only once, then 
the variable could be invisibly flagged as de-facto-const, and the 
compiler could then optimize it for MT and/or MP stuff, to its heart's 
content.

Such a compiler, or even an external tool, could give the programmer a 
list of all variables that are assigned more than once in the entire 
application, with filenames and line numbers.

Of course, in a Systems Language, there always are Intractable Ways to 
change data, but such a list could be invaluable for the conscientous 
programmer. Also *SafeD* might benefit even more from this list.

Chances are many programmers who currently don't use const, or who'd 
like to omit it, might even pay money for such a feature.

---

(1) Well, grepping might be a bit of an over-simplification. But, a 
compiler might have a switch to output a version of the program (a 
little like today's debugging or profiling switches) that actually 
writes a list of reassignemts. (Such a program version might even look 
at memory changes, and then report based on which variable owned that 
particular location, report stats. (Already Turbo Pascal 2.0 did 
something similar with runtime crash reports.) This might be easier than 
keeping track of variables and assignments, for all I know. Besides, 
then the facts are right, no matter how obscurely something is changed 
in the program.) The output of this program could be used by the 
compiler for constness hints.
Mar 30 2008
parent "Neil Vice" <sardonicpresence gmail.com> writes:
"Georg Wrede" <georg nospam.org> wrote in message 
news:47F04DD4.8020803 nospam.org...
 I'm not sure if the current way const is heading is for better (read, more 
 productive, i.e. safer and /faster/ ) programming, or if it is for better 
 compiler omtimizability in a multithread+multiprocessor setting, 
 forgetting the poor programmer.
I personally see the primary reason for const as the former and I think D2 is beginning to do that very well. I think as far as compiler optimisation goes, any declarations that state what can & can't happen to variables has the potential to be valuable. As such, provided there is also an advantage to the programmer and as such is not simply an inconvenience, declarations of this nature are desirable to include.
 Of course, the holy grail would be getting both, but I'm not so sure that 
 is even within reachability of D2. Maybe D3, though? In that case should 
 we try to get there one step at a time? But then, where should we draw the 
 line on how far we try to get with D2?
I see D2 as achieving more the safer programming aspect than the multiprocessor optimisation. I suspect that much more is required to achieve the latter but as I say, every little declaration helps =)
Mar 30 2008