Re: DData
Saaa wrote: How should I procede to get this functionallity into phobos? Nice job. You may want to add a bugzilla ticket marking it as an improvement with an attachment. Andrei
Stewart's Utility Library 0.05 release
Mostly additions to datetime: alignment fields for formatting, and a unixTime property. A few other tweaks and bug fixes have also been thrown in. http://pr.stewartsplace.org.uk/d/sutil/ Stewart.
Re: Incremental compilation with DMD
Tom S wrote: Walter Bright wrote: I don't really understand why the -lib approach is not working for your needs. I'm not sure what you mean by the -lib approach. Just how do you exactly apply it to incremental compilation? If my project has a few hundred modules and I change just one line in one function, I don't want to rebuild it with -lib all again. I thought you were referring to the proof-of-concept incremental build tool I posted yesterday which used -multiobj, as it should be possible to optimize it using -lib... I just haven't tried that yet. You only have to build one source file with -lib, not all of them.
Re: Incremental compilation with DMD
Walter Bright wrote: Tom S wrote: Walter Bright wrote: I don't really understand why the -lib approach is not working for your needs. I'm not sure what you mean by the -lib approach. Just how do you exactly apply it to incremental compilation? If my project has a few hundred modules and I change just one line in one function, I don't want to rebuild it with -lib all again. I thought you were referring to the proof-of-concept incremental build tool I posted yesterday which used -multiobj, as it should be possible to optimize it using -lib... I just haven't tried that yet. You only have to build one source file with -lib, not all of them. So you mean compiling each file separately? That's only an option if we turn to the C/C++ way of doing projects - using .di files just like C headers - *everywhere*. Only then can changes in .d files be localized to just one module and compiled quickly. Java and C# do without header files because (to my knowledge) they have no means of changing what's compiled based on the contents of an imported module (basically they lack metaprogramming). So we could give up and do it the C/C++ way with lots of duplicated code in headers (C++ is better here with allowing you to only implement methods of a class in the .cpp file instead of rewriting the complete class and filling in member functions, like the .d/.di approach would force) or we might have an incremental build tool that doesn't suck. This is the picture as I see it: * I need to rebuild all modules that import the changed modules, because some code in them might evaluate differently (static ifs on the imported modules, for instance - I explained that in my first post in this topic). * I need to compile them all at once, because compiling each of them in succession yields massively long compile times. * With your suggestion of using -lib, I assumed that you were suggesting building all these modules at once into a lib and then figuring out what to do with their object files one by one. * Some object files need to be extracted because otherwise module ctors won't be linked into the executable. * As this is incremental compilation, there will be object files from the previous build, some of which should not be linked, because that would cause multiple definition errors. * The obsoleted object files can't be simply removed, since they might contain comdat symbols needed by some objects outside of the newly compiled set (I gave an example in my first post, but can provide actual D code that illustrates this issue). Thus they have to be moved into a lib and only pulled into linking on demand. That's how my experimental build tool maps to the -lib approach. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Re: Incremental compilation with DMD
Tom S wrote: Walter Bright wrote: Tom S wrote: Walter Bright wrote: I don't really understand why the -lib approach is not working for your needs. I'm not sure what you mean by the -lib approach. Just how do you exactly apply it to incremental compilation? If my project has a few hundred modules and I change just one line in one function, I don't want to rebuild it with -lib all again. I thought you were referring to the proof-of-concept incremental build tool I posted yesterday which used -multiobj, as it should be possible to optimize it using -lib... I just haven't tried that yet. You only have to build one source file with -lib, not all of them. So you mean compiling each file separately? Yes. Or a subset of the files. That's only an option if we turn to the C/C++ way of doing projects - using .di files just like C headers - *everywhere*. Only then can changes in .d files be localized to just one module and compiled quickly. Java and C# do without header files because (to my knowledge) they have no means of changing what's compiled based on the contents of an imported module (basically they lack metaprogramming). So we could give up and do it the C/C++ way with lots of duplicated code in headers (C++ is better here with allowing you to only implement methods of a class in the .cpp file instead of rewriting the complete class and filling in member functions, like the .d/.di approach would force) or we might have an incremental build tool that doesn't suck. This is the picture as I see it: * I need to rebuild all modules that import the changed modules, because some code in them might evaluate differently (static ifs on the imported modules, for instance - I explained that in my first post in this topic). * I need to compile them all at once, because compiling each of them in succession yields massively long compile times. * With your suggestion of using -lib, I assumed that you were suggesting building all these modules at once into a lib and then figuring out what to do with their object files one by one. * Some object files need to be extracted because otherwise module ctors won't be linked into the executable. * As this is incremental compilation, there will be object files from the previous build, some of which should not be linked, because that would cause multiple definition errors. * The obsoleted object files can't be simply removed, since they might contain comdat symbols needed by some objects outside of the newly compiled set (I gave an example in my first post, but can provide actual D code that illustrates this issue). Thus they have to be moved into a lib and only pulled into linking on demand. That's how my experimental build tool maps to the -lib approach. What you can try is creating a database that is basically a lib (call it A.lib) of all the modules compiled with -lib. Then recompile all modules that depend on changed modules in one command, also with -lib, call it B.lib. Then for all the obj's in B, replace the corresponding ones in A.
Re: Incremental compilation with DMD
Walter Bright wrote: What you can try is creating a database that is basically a lib (call it A.lib) of all the modules compiled with -lib. Then recompile all modules that depend on changed modules in one command, also with -lib, call it B.lib. Then for all the obj's in B, replace the corresponding ones in A. That's what I'm getting at :) -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Re: Floating point rounding modes: we should restrict them slightly
Walter Bright wrote:
Don wrote:
PROPOSAL:
Change the spec by adding the line to float.html:
If the floating-point rounding mode is changed within a function, it
must be restored before the function exits. If this rule is violated
(for example, by the use of inline asm), the rounding mode used for
subsequent calculations is undefined.
But that doesn't allow for changing the rounding mode at a global level,
then rerunning one's computation to determine how rounding affects their
final result.
It doesn't prevent that at all. You just need to change the rounding
mode before running your computation (at the start of main(), for
example), and then reset it after performing the computation. What it
does do is prevent different terms within a single expression from
interacting which other.
eg
double foo() {
return x() + y();
}
x() and y() can use whichever rounding modes they like, and if they are
impure, they can affect one another, but under this proposal, they
cannot change the meaning of the addition inside foo().
Re: Floating point rounding modes: we should restrict them slightly
On 2009-09-13 06:14:02 -0400, Don nos...@nospam.com said:
double foo() {
return x() + y();
}
x() and y() can use whichever rounding modes they like, and if they are
impure, they can affect one another, but under this proposal, they
cannot change the meaning of the addition inside foo().
Problems still may occur if x and y do memoization however. You call
x() with one rounding mode, it memoize the results, then call x() with
another rounding mode and it reuses the previous results while it
shouldn't.
Basicaly, any memoization of x() should be discarded when you change
the rounding mode. For instance the compiler should not reuse the value
of x(), even if x is pure, in the following code:
auto a = x();
setRoundingMode(...);
auto b = x();
Basically, setRoundingMode should act as some sort of barrier for the
optimizer, but how?
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Modern Windows GUI visual styles
Tim M wrote: Daniel Keep Wrote: Tim M wrote: Microsoft says to use Application.EnableVisualStyles http://msdn.microsoft.com/en-us/library/system.windows.forms.application.enablevisualstyles.aspx Umm... you do realise that's for .NET, right? Run it through a debugger and you will probably find that both provide an abstraction over the same complicated win32 api functions. Or look at Mono's implementation. Or use Reflector http://www.red-gate.com/products/reflector/ -- it's free.
Re: XML ecosystem wrt D
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jarrett Billingsley wrote: On Sat, Sep 12, 2009 at 8:34 PM, div0 d...@users.sourceforge.net wrote: It seems on causal thought that it ought to be possible to machine translate it into D, unless Java has under gone massive change since the last time I played with it. So who's up for writing a Java to D translator? You mean Tioport? http://www.dsource.org/projects/tioport ty for the link, interesting. Not that I want an XSLT processor at the moment. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKrRS3T9LetA9XoXwRAqscAJ4yJvvmXw5a8Bl7sybDDFOx50e0KgCgwmtw qS48v02WXrgtACgxme6TYEE= =AGFD -END PGP SIGNATURE-
Re: std.string phobos
dsimcha Wrote:
== Quote from pc (peng2che...@yahoo.com)'s article
Is there a way to make the functions in std.string, such as replace, pure?
Many
pure functions are going to want to use these. Also, could some of them be
executable at compile time?
For me, using D2.032, this did not compile.
pure string replaceXX(string str){
return replace(str,XX,X);
}
If I am missing something, help!
For a function in D to pass the compiler checks for purity, it must only call
functions that are *marked as* being pure. If a function is not marked as
pure
but is de facto pure, it won't work. For example:
uint nPlus2(uint n) pure {
return nPlus1( nPlus1( n)); // Not pure.
}
uint nPlus1(uint n) {
return n + 1;
}
Many functions that are, in fact, pure, have not been annotated as such yet in
Phobos, since pure was implemented fairly recently. If you want to help out,
this
is fairly low hanging fruit.
Also, purity is very restrictive right now and is designed partly with thread
safety in mind. A function that truly has no side effects from an observable
behavior in a single thread point of view won't necessarily pass the compiler
as pure:
__gshared uint foo;
/* wasteTime() is impure even though it has no observable side
* effects in a single thread because it still (at least
* temporarily) manipulates global state, and thus could
* cause problems in multithreaded code. Furthermore, even if
* it were thread safe, it would be hard to prove for all but
* the simplest cases that functions like these have no
* observable side effects.*/
void wasteTime() pure { // Won't compile.
foo++;
foo--;
}
Thank you for the helpful comments.
Re helping out, I would like to help, but at this stage I feel that I need to
learn much much more before I can be of any use. (I am a recently retired
international income tax consultant). If I get up to speed, I will certainly
help.
I was thinking that it would be good if std.string was completely templated to
work for char, wchar and dchar (My main hobby is learning Chinese, so I have an
interest in unicode.) I also thought the functions should be pure. The first
step in this direction, and to learn D2, was to write
immutable(T)[][] csvSplit(T)(immutable(T)[], T sep=',', T quote='');
This worked out pretty well for string, wstring and dstring. (copy attached). I
take no credit for anything clever in the code (its all based on a lisp program
written by Alain Picard that is availble on the web -- it was by far the
easiest to understand).
Here's the catch -- I could not make csvSplit pure. The inner functions were
referencing cvsSplits local variables. I think that the problem only occurs in
templates. The following isolates the issue:
import std.stdio;
/*
ATTEMPT TO USE NESTED PURE FUNCTIONS IN A TEMPLATE.
All works fine unless you uncomment the third line in main. If you
do, dmd 2.032 yeilds:
pure.d(35): Error: pure nested function 'bar' cannot access mutable
data 'fooState'
pure.d(36): Error: pure nested function 'bar' cannot access mutable
data 'y'
pure.d(47): Error: template instance pure.fooPT!(char) error
instantiating
*/
//pure inner function, with concrete types - ok
pure string foo(string x, string y){
string fooState;
string bar(string x){
fooState = hello ;
return x ~ y;
}
return fooState ~ bar(x);
}
//potentially pure (?) templated version not labled as pure - ok
immutable(T)[] fooT(T)(immutable(T)[] x, immutable(T)[] y){
immutable(T)[] fooState;
immutable(T)[] bar(immutable(T)[] x){
fooState = hello ;
return x ~ y;
}
return fooState ~ bar(x);
}
//attempt to make templated version pure - no dice
pure immutable(T)[] fooPT(T)(immutable(T)[] x, immutable(T)[] y){
immutable(T)[] fooState;
immutable(T)[] bar(immutable(T)[] x){
fooState = hello ;
return x ~ y;
}
return fooState ~ bar(x);
}
void main(){
writeln(foo(p, c));
writeln(fooT(p, c));
//writeln(fooPT(p, c));
// Alain Picard -- the states
// figure how to acknowledge
// put in my string util module
//
module dcsv;
import std.string;
version(unittest){import std.conv;}
private enum {OUTSIDE_FIELD, IN_FIELD, IN_QUOTED_FIELD, AFTER_ENDING_QUOTE}
/* csvSplit
*
* Splits a line into its csv formatted fields
* Strips leading and trailing whitespace from fields, unless quoted
* The line can be string, wstring or dstring
*
*/
public immutable(T)[][] csvSplit(T)(immutable(T)[] line,
T fieldSepChar=',',
T quoteChar = '')
{
alias immutable(T)[] tstring;
immutable int EOL = -1;
tstring nullField = ;
int state;
int fieldBeg;
int charPos;
tstring[] fields;
bool fieldHasDoubleQuoteChars;
int numTrailingWhitespaceChars;
tstring reduceDoubles(T)(tstring str, T q){
tstring ret;
bool afterQuote = false;
foreach(T c;str){
if (c==q) {
if (afterQuote){
afterQuote = false;
Re: Incremental compilation with DMD
Tom S wrote: Walter Bright wrote: What you can try is creating a database that is basically a lib (call it A.lib) of all the modules compiled with -lib. Then recompile all modules that depend on changed modules in one command, also with -lib, call it B.lib. Then for all the obj's in B, replace the corresponding ones in A. That's what I'm getting at :) With this approach, you could wind up with some 'dead' obj files in A.lib, but aside from a bit of bloat in the lib file, they'll never wind up in the executable.
Re: Floating point rounding modes: we should restrict them slightly
Michel Fortin wrote:
On 2009-09-13 06:14:02 -0400, Don nos...@nospam.com said:
double foo() {
return x() + y();
}
x() and y() can use whichever rounding modes they like, and if they
are impure, they can affect one another, but under this proposal, they
cannot change the meaning of the addition inside foo().
Problems still may occur if x and y do memoization however.
Yes, but this is an orthogonal issue, which I have discussed previously.
Basicaly, any memoization of x() should be discarded when you change the
rounding mode.
Basically, setRoundingMode should act as some sort of barrier for the
optimizer, but how?
It's not a big deal, because rounding mode is changed so rarely, so you
don't need to exactly catch all the cases where memoisation can safely
be used; you only need to disallow all of the ones where it is unsafe.
I proposed two options: (1) by analogy to SafeD, allow rounding mode and
float exception flags to be respected only in specially marked modules
('module(advancedfloatingpoint)' or similar). Memoisation should be
disabled in such modules. (As a further optimisation, the compiler can
re-enable memoisation when such functions are called from
non-advancedfloatingpoint modules).
(2) provide a runtime call to disable memoisation. You'd be obliged to
call this every time you changed the rounding mode or exception status
from the default.
I favour (1) because it provides huge optimisation potential for modules
with default floating point.
The point of all my proposals on this topic, is that these features
cause a lot of trouble if they're completely unrestrained in the way
that C/C++ does it, but the semantics required to completely domesticate
them are not burdensome, and can be done without loss of useful
functionality.
Re: shared adventures in the realm of thread-safety.
Jason House Wrote:
I'm glad to see I'm not the only one trying to use shared. I tried to use it
with 2.031 and rapidly hit bug after bug... I submitted several bug reports
for basic functionality, and none of it appeared in the changelog.
http://d.puremagic.com/issues/show_bug.cgi?id=3089
shared methods no longer trigger errors in 2.032, this issue should be marked
as fixed, it must be a side effect from fixing another issue.
http://d.puremagic.com/issues/show_bug.cgi?id=3090
I just made a quick template this seems to work in 2.032:
immutable template isShared(T) {
static if(is(T U : shared U))
bool isShared = true;
else
bool isShared = false;
}
http://d.puremagic.com/issues/show_bug.cgi?id=3091
This one still isn't solved, I too found it annoying that you cant use 'new
shared Foo()'. You can however declare Foo as 'shared class Foo', this works
just like 'immutable class' or 'const class' by marking all properties and
members with the qualifier. As a side note, I would like the same behavior for
'static class'.
However using 'shared class' is not always the wanted behavior, you may only
want a subset of the members and properties to be shared.
We also miss a unique qualifier to allow unshared objects to be used in shared
contexts without the need for shared methods.
It's also awkward to use, const members may be called from either const or
mutable objects. Shared members must be called from shared objects, so why
allow a class to have shared and unshared members, if all instances are going
to be shared anyways? It makes it much harder to draw the line between shared
and unshared; you may have only a few objects actually shared, but you are
required to make all the other objects they may use shared, even if they are
synchronized or unique. This makes all the other contexts these objects are
used in as shared, and soon your entire program is shared.
Re: std.string phobos
pc wrote: dsimcha Wrote: == Quote from pc (peng2che...@yahoo.com)'s article Is there a way to make the functions in std.string, such as replace, pure? Many pure functions are going to want to use these. [snip] Here's the catch -- I could not make csvSplit pure. The inner functions were referencing cvsSplits local variables. I think that the problem only occurs in templates. The following isolates the issue: Looks like a bug. I wrote the patch which allowed 'pure' to work with nested functions, and it was one of my first patches (DMD 2.028). I probably missed this case (I probably didn't test with templated functions at all). Please put this test case into Bugzilla.
Re: Incremental compilation with DMD
Walter Bright wrote: Tom S wrote: Walter Bright wrote: What you can try is creating a database that is basically a lib (call it A.lib) of all the modules compiled with -lib. Then recompile all modules that depend on changed modules in one command, also with -lib, call it B.lib. Then for all the obj's in B, replace the corresponding ones in A. That's what I'm getting at :) With this approach, you could wind up with some 'dead' obj files in A.lib, but aside from a bit of bloat in the lib file, they'll never wind up in the executable. I'm feeling horribly guilty for having asked for module-level static if(). I have a dreadful suspicion that it might have been a profoundly bad idea.
Re: shared adventures in the realm of thread-safety.
Graham St Jack Wrote:
I'm also having the same problems.
As Jeremie said, as soon as you start introducing shared methods (via
synchronized for example), you rapidly get into trouble that can only be
overcome by excessive casting.
It may be possible to contain the problem by refactoring multi-threaded
code so that the shared objects are very small and simple, but even then
the casting required is too much. This approach might be ok if you could
define classes as being shared or immutable, and ALL instance of them
were then implicitly shared or immutable. Also, immutable objects should
be implicitly shareable.
I agree, this is also one of my main concerns with shared in its current state.
It's an amazing and powerful concept and has the potential to make multi-thread
code much easier and safer to write. But all the required casting is killing
the safety, and makes it harder to use than it would be not having shared at
all. The lack of an unique qualifier certainly doesn't help either.
Unique data could only be used for aggregate properties, const/immutable data
would also be implicitly unique. This qualifier alone would simplify shared
quite a lot, allowing the use of unshared objects in shared contexts safely.
The compiler should make the distinction between shared code and shared data
and allow both shared and unshared instances to use shared methods, just like
both const and mutable instances may call const methods. An error should also
be triggered when calling a shared method of a shared object without
synchronization, and maybe have a __sync keyword to override this. If a
synchronized method is called from a non-shared object, no synchronization
takes place.
Allow me to illustrate my point with some code:
class Foo {
int bar() shared { return a; }
__sync bar2() { synchronized(this) return a; }
synchronized void foo() { a = 1; }
int a;
}
auto foo1 = new shared(Foo)();
auto foo2 = new Foo;
foo1.foo(); // ok, synchronized call
synchronized(foo1) foo1.foo(); // warning: recursive synchronization
foo2.foo(); // ok, unsynchronized call
synchronized(foo2) foo2.foo(); // ok synchronized call
foo1.bar(); // error, unsynchronized call to bar() shared
synchronized(foo1) foo1.bar(); // ok, synchronized call
foo2.bar(); // ok, unsynchronized call
synchronized(foo1) foo1.bar(); // ok, synchronized call
foo1.bar2(); // ok, method handles synchronized
synchronized(foo1) foo1.bar2(); // warning, recursive synchronization
foo2.bar2(); // ok, method handles synchronized, even on unshared object
synchronized(foo2) foo2.bar2(); // warning, recursive synchronization, even on
unshared object
That's about it, I believe this behavior would allow quite a number of
multi-threaded techniques to be easily implemented and documented. It would
only be the most natural thing since its quite similar to how const works.
Re: shared adventures in the realm of thread-safety.
Jeremie Pelletier Wrote: Jason House Wrote: I'm glad to see I'm not the only one trying to use shared. I tried to use it with 2.031 and rapidly hit bug after bug... I submitted several bug reports for basic functionality, and none of it appeared in the changelog. http://d.puremagic.com/issues/show_bug.cgi?id=3089 shared methods no longer trigger errors in 2.032, this issue should be marked as fixed, it must be a side effect from fixing another issue. *sigh*
Re: Floating point rounding modes: we should restrict them slightly
Walter Bright wrote: Don wrote: PROPOSAL: Change the spec by adding the line to float.html: If the floating-point rounding mode is changed within a function, it must be restored before the function exits. If this rule is violated (for example, by the use of inline asm), the rounding mode used for subsequent calculations is undefined. But that doesn't allow for changing the rounding mode at a global level, then rerunning one's computation to determine how rounding affects their final result. Ok, I understand now. This makes sense.
Re: Floating point rounding modes: we should restrict them slightly
Don wrote: PROPOSAL: Change the spec by adding the line to float.html: If the floating-point rounding mode is changed within a function, it must be restored before the function exits. If this rule is violated (for example, by the use of inline asm), the rounding mode used for subsequent calculations is undefined. I added it into float.html for D2.
Re: Template Metaprogramming Made Easy (Huh?)
- If programs run quickly it saves some time. A good language has to try to save time in all those ways and more. Tks bearophile for that extensive writeup. A good read. btw. Downloaded the Bud tool (on linux) but couldn't get it to compile. First had to rename usage of macro to makro then it bitched about some missing module so I gave up. -- Justin
Re: shared adventures in the realm of thread-safety.
Robert Jacques Wrote:
On Sun, 13 Sep 2009 15:04:57 -0400, Jeremie Pelletier jerem...@gmail.com
wrote:
[snip]
Unique data could only be used for aggregate properties, const/immutable
data would also be implicitly unique. This qualifier alone would
simplify shared quite a lot, allowing the use of unshared objects in
shared contexts safely.
Neither const nor immutable data can be considered unique. First, any
const data may be being mutated by another routine, so it can't be safely
accessed without synchronization. Second, unique data is mutable while
const/immutable data is not. Third, most implementations of unique allow
for deterministic memory reclamation, which isn't possible if the unique
data might actually be const/immutable.
Good points, I can only agree with you here. However I still believe immutable
data should be able to be used in shared contexts without being 'shared' or
protected by a monitor.
The compiler should make the distinction between shared code and shared
data and allow both shared and unshared instances to use shared methods,
just like both const and mutable instances may call const methods. An
error should also be triggered when calling a shared method of a shared
object without synchronization, and maybe have a __sync keyword to
override this. If a synchronized method is called from a non-shared
object, no synchronization takes place.
I think you have the wrong paradigm in mind. Shared and non-shared aren't
mutable and const. They're mutable and immutable. From a technical
perspective, synchronization of shared methods are handled by the callee,
so there is no way not to call them and non-shared objects don't have a
monitor that can be synchronized. Now you can have the compiler use the
same code to generate two different object types (vtables, object layouts,
etc) with have the same interface, but that doesn't sound like what you're
suggesting.
I know that shared/unshared is not const/mutable. What I meant is that right
now in D if a method is 'shared' it cannot be called from a non-shared object,
which makes unshared instance of the class unusable without plenty of dirty
casts. Take the following objects:
class Foo { void foo() const; }
class Bar { void bar() shared; }
Foo foo; foo.foo(); // ok, mutable object can call const method
Bar bar; bar.bar(); // error, unshared object may not call shared method
I had only presented the concept, your idea of using two virtual tables for
shared/unshared instances is also what I had in mind for the implementation,
and it would give exactly the behavior I had in mind.
Allow me to illustrate my point with some code:
class Foo {
int bar() shared { return a; }
__sync bar2() { synchronized(this) return a; }
synchronized void foo() { a = 1; }
int a;
}
auto foo1 = new shared(Foo)();
auto foo2 = new Foo;
foo1.foo(); // ok, synchronized call
synchronized(foo1) foo1.foo(); // warning: recursive synchronization
Why a warning? Monitors are designed to handle recursive synchronization.
Its a performance issue that can easily be avoided, but still generates valid
code.
foo2.foo(); // ok, unsynchronized call
synchronized(foo2) foo2.foo(); // ok synchronized call
foo1.bar(); // error, unsynchronized call to bar() shared
synchronized(foo1) foo1.bar(); // ok, synchronized call
foo2.bar(); // ok, unsynchronized call
synchronized(foo1) foo1.bar(); // ok, synchronized call
foo1.bar2(); // ok, method handles synchronized
synchronized(foo1) foo1.bar2(); // warning, recursive synchronization
foo2.bar2(); // ok, method handles synchronized, even on unshared object
synchronized(foo2) foo2.bar2(); // warning, recursive synchronization,
even on unshared object
That's about it, I believe this behavior would allow quite a number of
multi-threaded techniques to be easily implemented and documented. It
would only be the most natural thing since its quite similar to how
const works.
The major benefit of const isn't method declaration, but object use: i.e.
only having to declare func(const T var) and not func(immutable T var) and
func(T var). Currently, there's no planned type to fill this role though
there have been some proposals.
I disagree, I think const methods are just as useful as const objects, since
they are the only methods that can be called on such objects. They do not
however prevent you from calling them on a mutable object. This is the behavior
I want with shared too; unshared objects should be able to call shared methods,
but shared objects should only be able to call shared methods.
P.S. Shouldn't 'a' be either private or protected?
It should, but this was just an example ;)
P.S.S. Bartosz Milewski has a good series of blogs on multi-threading
(with an eye on how to do it well in D).
I know, this is what sparked my interest for shared in
Re: Floating point rounding modes: we should restrict them slightly
Don wrote: snip Floating point settings are just another case of the same thing, except that currently violations in relation to the former are allowed. There's a fundamental difference between them: the floating point settings are a hardware feature and it is IMPOSSIBLE to avoid them. Actually, you _can_ avoid changing the floating point settings in the course of an average program. But still You can choose not to use locale settings. Or, you can pass them as a parameter, which doesn't work for floating point settings. As long as it's the built-in arithmetic operators you're concerned about. But that said, wrapping every arithmetic operation in a function to purify it of dependence on floating point settings wouldn't be ideal. Please do not get sidetracked on pure functions, it is orthogonal to this issue. I'm not sure about this. ISTM arithmetic operators are essentially pure functions, and so the compiler may treat them as such. Stewart.
Re: Incremental compilation with DMD
Don wrote: Walter Bright wrote: Tom S wrote: Walter Bright wrote: What you can try is creating a database that is basically a lib (call it A.lib) of all the modules compiled with -lib. Then recompile all modules that depend on changed modules in one command, also with -lib, call it B.lib. Then for all the obj's in B, replace the corresponding ones in A. That's what I'm getting at :) With this approach, you could wind up with some 'dead' obj files in A.lib, but aside from a bit of bloat in the lib file, they'll never wind up in the executable. I'm feeling horribly guilty for having asked for module-level static if(). I have a dreadful suspicion that it might have been a profoundly bad idea. No need to feel guilty. This problem actually manifests itself in many other cases than just static if, e.g. changing an alias in the modified module, adding some fields to a struct or methods to a class. Basically anything that would bite us if we had C/C++ projects solely in .h files (except multiple definition errors). I've prepared some examples (.d and .bat files) of these at http://h3.team0xf.com/dependencyFail.7z (-version is used instead of literally changing the code). I have no idea how Java or C# deal with these. Could be smart linking or some sort of static analysis. As for the 'dead' obj files, one could run a 'garbage collection' step from time to time ;) -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Re: Template Metaprogramming Made Easy (Huh?)
bearophile Wrote: Justin Johansson: would you mind saying what salient things there are about D that presumably attracts to the language. It just helps to know why others are here as one ventures into new territory. That's not an easy question. This is a personal answer, other people will like other sides of D. I like D1/D2 for: - I don't think of it as a propetary language, like C#. - Sometimes I want the freedom to use memory as I like, with structs, and even unions. If you have large datasets you find that using more than 20 bytes for a number as in Python doesn't help. Values also reduce indirection, this speeds up things. This allows a more efficient usage of memory, and this helps increase cache locality, that increases performance. Unfortunately GC-managed D pointers can't be tagged, so I have to use memory from the C heap for them. And sometimes you need pointers. That's why I'd like D to have more/better ways to increase safety when using pointers (like using memory regions when not in release mode, etc). I haven't had to use the C heap whatsoever so far in D, could you give me an example of where you need it? In fact, the *only* place I use the C heap is in my garbage collector's internals, for pool structs and mark ranges. I use pointers to GC memory all the time too, there are plenty of algorithms, especially in loops, that can run faster with pointer arithmetic than slices and it's still the fastest way to pass struct references around. - I like this newsgroups, I can talk to people, and they sometimes answer my numerous questions. I am learning a lot. Sometimes I receive no answers, but it's acceptable. For its nature this newsgroup attracts some strange people too. - I often use Python, it's the language I like more, but for some purposes it's too much slow. And I am tired of writing vectorized code in NumPy and the like. Cython reference count makes me sick and ShedSkin while nice is a failed experiment. D feels like freedom, while sometimes using Python feels like programming with mittens for me. - There are some things that I'd like to see in a language, and D being in development still and being not controlled by an ivory tower committee give me the illusion to see some of my ideas realized. So far I haven't influenced a lot the development of D. On the other hand if everyone can influence a lot the language the result may be a patchwork. So some dynamic compromise has to be found every day. I also like this community driven model, but this forum has more people submitting ideas than people able to implement them on time, I'm pretty sure the TODO list is rather huge at this time :) I for one much prefer D development the way it is now than the working group model used by the W3C or Khronos for example. The public bugzilla is really nice too, once you get used to it, one of the issues I submitted got fixed in 2.032, I've also sent maybe 3 or 4 patches to the compiler source in other issues so far too, hopefully they'll be used in 2.033! - D looks a lot like C, yet in D I can write code several times faster than C. Sometimes 5-10 times faster. This is an enormous difference. Indeed, and sometimes it's way faster than that. I've ported many C headers to D and I'm always amazed at how many things I can throw out, just the DirectX headers were at least 50% smaller in D and MUCH easier to read. Such simplicity is also reflected in the compiler by having quite a lot less tokens and parse nodes to create and analyze. I must admit however that I sometimes miss the C preprocessor, or at least wish mixins had a syntax closer to that used by the C preprocessor. But it's a good idea to keep D without a preprocessor, its much better for everything to have a scope. - I am quite sensitive to syntax noise, boilerplate code. I like elegance, clarity in semantics, I hate corner cases, yet I want a language that's efficient, readable, and the less bug-prone as possible. C++ looks too much complex for me. D1 is simple enough for me, and D2 is getting a bit too much complex. I may appreciate the idea of a D 1.5 language that fixes some holes and limits of D1 while keeping language simple enough (struct constructors, and few other things. Such things don't significantly increase the difficulty in using the language). C++ isn't anymore complex than D2, its syntax just isn't as elegant. Other than multiple inheritance which is partially solved through object composition, I can't think of many features C++ has over D2. I can name quite a few features D2 has over C++ :) What I like about D is that while its elegant, it still allows for dirty work to be done when you need it. You don't need to code your application core in C and your application behavior in a scripting language on top of the C core. D allows you to write it all in one language with the same productivity, if not better productivity for
Re: Floating point rounding modes: we should restrict them slightly
Walter Bright: Don: PROPOSAL: Change the spec by adding the line to float.html: If the floating-point rounding mode is changed within a function, it must be restored before the function exits. If this rule is violated (for example, by the use of inline asm), the rounding mode used for subsequent calculations is undefined. I added it into float.html for D2. An important purpose of a not bug-prone language is remove as many undefined situations as possible. If you add that to D2 specs, can the compiler catch at compile time all cases of violations to that rule? D has something for the actions that must be done before the function exits, the scope(exit). Can something like that be used to automatically avoid undefined rounding situations? Bye, bearophile
Re: Template Metaprogramming Made Easy (Huh?)
Jeremie Pelletier wrote: I haven't had to use the C heap whatsoever so far in D, could you give me an example of where you need it? In fact, the *only* place I use the C heap is in my garbage collector's internals, for pool structs and mark ranges. I use pointers to GC memory all the time too, there are plenty of algorithms, especially in loops, that can run faster with pointer arithmetic than slices and it's still the fastest way to pass struct references around. I use the C heap a lot when I need slabs of memory that the GC should not look into for performance reasons. This includes images/textures, mesh data and some data structures that I release manually - again, for efficiency reasons. - I like how D doesn't totally ignore safety as C does, in D sometimes the default way is the safer one, and the unsafe way is used only where you ask for it. I'd like to see more safeties added to D, like optional run-time and compile-time integral overflow tests, some pointer safety, better template error messages (template constraints help some in such regard), stack traces, less compiler bugs, safer casts (in C# you need explicit casts to convert double = float), a safer printf, some optional annotations inspired by Plint (a lint program) to give more semantics to the compiler, that can be used to both speed up code and avoid bugs. There's lot that can be done in this regard. And release-mode performance can be usually kept unchanged. Stack traces is a feature for the runtime, I made one for mine, which shows a dialog window with the stack trace, current registers values, loaded modules and whatnot. Took me almost a week to piece together my CodeView reader, I still need a DWARF reader for linux. I'm gonna try and implement it in druntime and submit the patch to bugzilla. Tango's runtime already does stack tracing on Windows and *NIX, however its CV parser is subject to some licensing issues :( Perhaps you could release yours under some liberal license so it can be plugged there? :) -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Re: shared adventures in the realm of thread-safety.
On 2009-09-13 18:08:57 -0400, Jeremie Pelletier jerem...@gmail.com said: foo1.foo(); // ok, synchronized call synchronized(foo1) foo1.foo(); // warning: recursive synchronization Why a warning? Monitors are designed to handle recursive synchronization. Its a performance issue that can easily be avoided, but still generates valid code. Also, some people consider recursive locks as potential design flaws. http://landheer-cieslak.com/wordpress/?p=57 -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Floating point rounding modes: we should restrict them slightly
bearophile wrote: An important purpose of a not bug-prone language is remove as many undefined situations as possible. That's right. If you add that to D2 specs, can the compiler catch at compile time all cases of violations to that rule? Unlikely. But that has to be weighed against the former behavior being defined in a useless way. D has something for the actions that must be done before the function exits, the scope(exit). Can something like that be used to automatically avoid undefined rounding situations? Using an RAII object to do it might be better.
Re: Template Metaprogramming Made Easy (Huh?)
Jeremie Pelletier wrote: Tom S Wrote: Jeremie Pelletier wrote: I haven't had to use the C heap whatsoever so far in D, could you give me an example of where you need it? In fact, the *only* place I use the C heap is in my garbage collector's internals, for pool structs and mark ranges. I use pointers to GC memory all the time too, there are plenty of algorithms, especially in loops, that can run faster with pointer arithmetic than slices and it's still the fastest way to pass struct references around. I use the C heap a lot when I need slabs of memory that the GC should not look into for performance reasons. This includes images/textures, mesh data and some data structures that I release manually - again, for efficiency reasons. The garbage collector in D already mark allocations which contains pointers and scans these only. If you want to know if a type contains pointers, check the 'flags' property of the typeinfo or classinfo, test for bit0 and bit1 respectively. This is what the GC uses at runtime when allocating memory to know if it should tag the allocation as containing possible pointers. Yea I know, but I want structures with pointers manually managed as well. I myself allocate all my meshes and textures directly on the GC and I'm pretty sure its faster than C's malloc and much safer. Hm, why would it be faster with the GC than malloc? I'm pretty sure it's the opposite :P Plus, I could use a specialized malloc implementation, like TLSF. - I like how D doesn't totally ignore safety as C does, in D sometimes the default way is the safer one, and the unsafe way is used only where you ask for it. I'd like to see more safeties added to D, like optional run-time and compile-time integral overflow tests, some pointer safety, better template error messages (template constraints help some in such regard), stack traces, less compiler bugs, safer casts (in C# you need explicit casts to convert double = float), a safer printf, some optional annotations inspired by Plint (a lint program) to give more semantics to the compiler, that can be used to both speed up code and avoid bugs. There's lot that can be done in this regard. And release-mode performance can be usually kept unchanged. Stack traces is a feature for the runtime, I made one for mine, which shows a dialog window with the stack trace, current registers values, loaded modules and whatnot. Took me almost a week to piece together my CodeView reader, I still need a DWARF reader for linux. I'm gonna try and implement it in druntime and submit the patch to bugzilla. Tango's runtime already does stack tracing on Windows and *NIX, however its CV parser is subject to some licensing issues :( Perhaps you could release yours under some liberal license so it can be plugged there? :) Sure, I wouldn't mind at all, I'm not into licenses myself so I might just release it to public domain. I'll try and get a standalone package ready and post it somewhere, I just don't know where yet :x Sweet :D As for a place, there are plenty of options, e.g. http://dsource.org/projects/scrapple/ or a separate dsource project. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Re: Template Metaprogramming Made Easy (Huh?)
Tom S Wrote: Jeremie Pelletier wrote: Tom S Wrote: Jeremie Pelletier wrote: I haven't had to use the C heap whatsoever so far in D, could you give me an example of where you need it? In fact, the *only* place I use the C heap is in my garbage collector's internals, for pool structs and mark ranges. I use pointers to GC memory all the time too, there are plenty of algorithms, especially in loops, that can run faster with pointer arithmetic than slices and it's still the fastest way to pass struct references around. I use the C heap a lot when I need slabs of memory that the GC should not look into for performance reasons. This includes images/textures, mesh data and some data structures that I release manually - again, for efficiency reasons. The garbage collector in D already mark allocations which contains pointers and scans these only. If you want to know if a type contains pointers, check the 'flags' property of the typeinfo or classinfo, test for bit0 and bit1 respectively. This is what the GC uses at runtime when allocating memory to know if it should tag the allocation as containing possible pointers. Yea I know, but I want structures with pointers manually managed as well. Then just inform the GC to not scan the allocations you want, or better yet have a static ctor modify the flag of the typeinfo you don't want scanned. I myself allocate all my meshes and textures directly on the GC and I'm pretty sure its faster than C's malloc and much safer. Hm, why would it be faster with the GC than malloc? I'm pretty sure it's the opposite :P Plus, I could use a specialized malloc implementation, like TLSF. The D GC is already specialized, and given its being used quite a lot in D, there are good chances its already sitting in the CPU cache, its heap already having the available memory block waiting on a freelist, or if the alloc is more than 0x1000 bytes, the pages available in a pool. You'd need to use malloc quite a lot to get the same optimal performance, and mixing the two would affect the performance of both. - I like how D doesn't totally ignore safety as C does, in D sometimes the default way is the safer one, and the unsafe way is used only where you ask for it. I'd like to see more safeties added to D, like optional run-time and compile-time integral overflow tests, some pointer safety, better template error messages (template constraints help some in such regard), stack traces, less compiler bugs, safer casts (in C# you need explicit casts to convert double = float), a safer printf, some optional annotations inspired by Plint (a lint program) to give more semantics to the compiler, that can be used to both speed up code and avoid bugs. There's lot that can be done in this regard. And release-mode performance can be usually kept unchanged. Stack traces is a feature for the runtime, I made one for mine, which shows a dialog window with the stack trace, current registers values, loaded modules and whatnot. Took me almost a week to piece together my CodeView reader, I still need a DWARF reader for linux. I'm gonna try and implement it in druntime and submit the patch to bugzilla. Tango's runtime already does stack tracing on Windows and *NIX, however its CV parser is subject to some licensing issues :( Perhaps you could release yours under some liberal license so it can be plugged there? :) Sure, I wouldn't mind at all, I'm not into licenses myself so I might just release it to public domain. I'll try and get a standalone package ready and post it somewhere, I just don't know where yet :x Sweet :D As for a place, there are plenty of options, e.g. http://dsource.org/projects/scrapple/ or a separate dsource project. I thought of that, but I don't feel like opening a project for just a few random code snippets or standalone classes. I think I'll just post it in this forum and let interested people grab it for now.
Re: Template Metaprogramming Made Easy (Huh?)
Jeremie Pelletier wrote: Tom S Wrote: Jeremie Pelletier wrote: I myself allocate all my meshes and textures directly on the GC and I'm pretty sure its faster than C's malloc and much safer. Hm, why would it be faster with the GC than malloc? I'm pretty sure it's the opposite :P Plus, I could use a specialized malloc implementation, like TLSF. The D GC is already specialized, and given its being used quite a lot in D, there are good chances its already sitting in the CPU cache, its heap already having the available memory block waiting on a freelist, or if the alloc is more than 0x1000 bytes, the pages available in a pool. You'd need to use malloc quite a lot to get the same optimal performance, and mixing the two would affect the performance of both. It might be specialized for _something_, but it definitely isn't real-time systems. I'd say with my use cases there's a very poor chance the GC is sitting in the CPU cache since most of the time my memory is preallocated and managed by specialized structures and/or malloc. I've found that using the GC only for the hard-to-manually-manage objects works best. The rest is handled by malloc and the GC has a very shallow vision of the world thus its collection runs are very fast. Of course there's a drawback that both the GC and malloc will have some pages cached, wasting memory, but I don't let the GC touch too much so it should be minimal. YMMV of course - all depends on the memory allocation patterns of the application. - I like how D doesn't totally ignore safety as C does, in D sometimes the default way is the safer one, and the unsafe way is used only where you ask for it. I'd like to see more safeties added to D, like optional run-time and compile-time integral overflow tests, some pointer safety, better template error messages (template constraints help some in such regard), stack traces, less compiler bugs, safer casts (in C# you need explicit casts to convert double = float), a safer printf, some optional annotations inspired by Plint (a lint program) to give more semantics to the compiler, that can be used to both speed up code and avoid bugs. There's lot that can be done in this regard. And release-mode performance can be usually kept unchanged. Stack traces is a feature for the runtime, I made one for mine, which shows a dialog window with the stack trace, current registers values, loaded modules and whatnot. Took me almost a week to piece together my CodeView reader, I still need a DWARF reader for linux. I'm gonna try and implement it in druntime and submit the patch to bugzilla. Tango's runtime already does stack tracing on Windows and *NIX, however its CV parser is subject to some licensing issues :( Perhaps you could release yours under some liberal license so it can be plugged there? :) Sure, I wouldn't mind at all, I'm not into licenses myself so I might just release it to public domain. I'll try and get a standalone package ready and post it somewhere, I just don't know where yet :x Sweet :D As for a place, there are plenty of options, e.g. http://dsource.org/projects/scrapple/ or a separate dsource project. I thought of that, but I don't feel like opening a project for just a few random code snippets or standalone classes. I think I'll just post it in this forum and let interested people grab it for now. WORKSFORME :) -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Re: shared adventures in the realm of thread-safety.
On Sun, 13 Sep 2009 18:08:57 -0400, Jeremie Pelletier jerem...@gmail.com
wrote:
Robert Jacques Wrote:
On Sun, 13 Sep 2009 15:04:57 -0400, Jeremie Pelletier
jerem...@gmail.com
wrote:
[snip]
Unique data could only be used for aggregate properties,
const/immutable
data would also be implicitly unique. This qualifier alone would
simplify shared quite a lot, allowing the use of unshared objects in
shared contexts safely.
Neither const nor immutable data can be considered unique. First, any
const data may be being mutated by another routine, so it can't be
safely
accessed without synchronization. Second, unique data is mutable while
const/immutable data is not. Third, most implementations of unique allow
for deterministic memory reclamation, which isn't possible if the unique
data might actually be const/immutable.
Good points, I can only agree with you here. However I still believe
immutable data should be able to be used in shared contexts without
being 'shared' or protected by a monitor.
One of the purposes behind immutable was lock-free access. As far as I
know you can use immutable data in shared contexts today without any other
modifiers. A quick test seems to indicate this works today, but if you've
got a test case where it doesn't, I'd recommend filing it as a bug.
The compiler should make the distinction between shared code and
shared
data and allow both shared and unshared instances to use shared
methods,
just like both const and mutable instances may call const methods. An
error should also be triggered when calling a shared method of a
shared
object without synchronization, and maybe have a __sync keyword to
override this. If a synchronized method is called from a non-shared
object, no synchronization takes place.
I think you have the wrong paradigm in mind. Shared and non-shared
aren't
mutable and const. They're mutable and immutable. From a technical
perspective, synchronization of shared methods are handled by the
callee,
so there is no way not to call them and non-shared objects don't have a
monitor that can be synchronized. Now you can have the compiler use the
same code to generate two different object types (vtables, object
layouts,
etc) with have the same interface, but that doesn't sound like what
you're
suggesting.
I know that shared/unshared is not const/mutable. What I meant is that
right now in D if a method is 'shared' it cannot be called from a
non-shared object, which makes unshared instance of the class unusable
without plenty of dirty casts. Take the following objects:
class Foo { void foo() const; }
class Bar { void bar() shared; }
Foo foo; foo.foo(); // ok, mutable object can call const method
Bar bar; bar.bar(); // error, unshared object may not call shared method
I had only presented the concept, your idea of using two virtual tables
for shared/unshared instances is also what I had in mind for the
implementation, and it would give exactly the behavior I had in mind.
Bartosz took the concept one step further: when declared as shared, all
methods are implicitly wrapped in synchronize blocks. He then added a
keyword for more manual, lock-free style programming. But this syntactic
sugar isn't implemented yet.
Allow me to illustrate my point with some code:
class Foo {
int bar() shared { return a; }
__sync bar2() { synchronized(this) return a; }
synchronized void foo() { a = 1; }
int a;
}
auto foo1 = new shared(Foo)();
auto foo2 = new Foo;
foo1.foo(); // ok, synchronized call
synchronized(foo1) foo1.foo(); // warning: recursive synchronization
Why a warning? Monitors are designed to handle recursive
synchronization.
Its a performance issue that can easily be avoided, but still generates
valid code.
Really? Every public method that calls another public method (of the same
object) results in recursive synchronization. And if your example was
longer than a one liner, you'd also have to have recursive
synchronization. There are ways to reduce recursive synchronization, like
public wrappers of protected/private methods, but they are not always
appropriate or feasible for the use case. BTW, in general the threshold
for what's a warning in DMD is generally a lot higher than other compilers
(on the theory that if warnings are generated for every build you'll never
read them)
[snip]
Bike-shed: I've always preferred the CSP/pi-calculas term 'mobile' for
the
concept of 'unique'. I think mobile better expresses the concept with
regard to multi-threading, where mobile is used to cheaply transfer data
between threads (i.e. it moves around/can move between threads, but
isn't
shared between them). I find 'unique' to mainly convey the memory
storage
aspect of the concept, which is less important outside of C/C++.
Maybe this is where 'volatile' could come back, from what I know it's
still a reserved keyword in D and would fit nicely this
Re: Template Metaprogramming Made Easy (Huh?)
Tom S Wrote: Jeremie Pelletier wrote: Tom S Wrote: Jeremie Pelletier wrote: I myself allocate all my meshes and textures directly on the GC and I'm pretty sure its faster than C's malloc and much safer. Hm, why would it be faster with the GC than malloc? I'm pretty sure it's the opposite :P Plus, I could use a specialized malloc implementation, like TLSF. The D GC is already specialized, and given its being used quite a lot in D, there are good chances its already sitting in the CPU cache, its heap already having the available memory block waiting on a freelist, or if the alloc is more than 0x1000 bytes, the pages available in a pool. You'd need to use malloc quite a lot to get the same optimal performance, and mixing the two would affect the performance of both. It might be specialized for _something_, but it definitely isn't real-time systems. I'd say with my use cases there's a very poor chance the GC is sitting in the CPU cache since most of the time my memory is preallocated and managed by specialized structures and/or malloc. I've found that using the GC only for the hard-to-manually-manage objects works best. The rest is handled by malloc and the GC has a very shallow vision of the world thus its collection runs are very fast. Of course there's a drawback that both the GC and malloc will have some pages cached, wasting memory, but I don't let the GC touch too much so it should be minimal. YMMV of course - all depends on the memory allocation patterns of the application. I understand your points for using a separate memory manager, and I agree with you that having less active allocations make for faster sweeps, no matter how little of them are scanned for pointers. However I just had an idea on how to implement generational collection on a non-moving GC which should solve your issues (and well, mines too) with the collector not being fast enough. I need to do some hacking on my custom GC first, but I believe it could give yet another performance boost. I'll add my memory manager to my list of code modules to make public :)
Re: Template Metaprogramming Made Easy (Huh?)
Jeremie Pelletier wrote: Tom S Wrote: Jeremie Pelletier wrote: Tom S Wrote: Jeremie Pelletier wrote: I myself allocate all my meshes and textures directly on the GC and I'm pretty sure its faster than C's malloc and much safer. Hm, why would it be faster with the GC than malloc? I'm pretty sure it's the opposite :P Plus, I could use a specialized malloc implementation, like TLSF. The D GC is already specialized, and given its being used quite a lot in D, there are good chances its already sitting in the CPU cache, its heap already having the available memory block waiting on a freelist, or if the alloc is more than 0x1000 bytes, the pages available in a pool. You'd need to use malloc quite a lot to get the same optimal performance, and mixing the two would affect the performance of both. It might be specialized for _something_, but it definitely isn't real-time systems. I'd say with my use cases there's a very poor chance the GC is sitting in the CPU cache since most of the time my memory is preallocated and managed by specialized structures and/or malloc. I've found that using the GC only for the hard-to-manually-manage objects works best. The rest is handled by malloc and the GC has a very shallow vision of the world thus its collection runs are very fast. Of course there's a drawback that both the GC and malloc will have some pages cached, wasting memory, but I don't let the GC touch too much so it should be minimal. YMMV of course - all depends on the memory allocation patterns of the application. I understand your points for using a separate memory manager, and I agree with you that having less active allocations make for faster sweeps, no matter how little of them are scanned for pointers. However I just had an idea on how to implement generational collection on a non-moving GC which should solve your issues (and well, mines too) with the collector not being fast enough. I need to do some hacking on my custom GC first, but I believe it could give yet another performance boost. I'll add my memory manager to my list of code modules to make public :) Sounds great, I can't wait! :D -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Reading till the end of standard input
I am using dmd v2.032 and trying to read int values from the standard input:
import std.cstream;
void main()
{
while (!din.eof()) {
int value;
din.readf(value);
if (!din.eof()) {
dout.writefln(read: , value);
}
}
}
1) If I
- start the program in bash under Linux
- enter a few values
- press Ctrl-D to end the input,
that program gets stuck in the loop; is this a bug? (I will open a bug if you
agree.)
2) I know that there is no need to read past the end of the stream to put it
into EOF. Is that right? If so, the check within the while loop is unnecessary,
right?
Thank you,
Ali
[Issue 3314] rdmd uses chdir which does not work with bash
http://d.puremagic.com/issues/show_bug.cgi?id=3314 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com AssignedTo|nob...@puremagic.com|and...@metalanguage.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3315] ICE(mtype.c) floating point converted to an integer type and passed to a function, when certain incompatible overloads exist
http://d.puremagic.com/issues/show_bug.cgi?id=3315 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2009-09-13 03:33:55 PDT --- This is probably the same as the nasty regression bug 3173. I'd submitted the patch to Walter just before 2.032 was released, but unfortunately it missed the deadline. We considered delaying the release of 2.032 by another few days because of it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3283] glue.c assertion with no info
http://d.puremagic.com/issues/show_bug.cgi?id=3283 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Don clugd...@yahoo.com.au 2009-09-13 03:39:51 PDT --- Closing this as a duplicate of bug 2962, since it has no test case and otherwise appears to be the same. Reopen if you are able to establish that it is different. (BTW, the patch in 2962 will help in tracking down the bug). *** This issue has been marked as a duplicate of issue 2962 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2962] ICE(glue.c) or bad codegen passing variable as template value parameter
http://d.puremagic.com/issues/show_bug.cgi?id=2962 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||alvcas...@yahoo.es --- Comment #19 from Don clugd...@yahoo.com.au 2009-09-13 03:39:51 PDT --- *** Issue 3283 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1934] ICE(e2ir.c) using static array as AA key
http://d.puremagic.com/issues/show_bug.cgi?id=1934 Don clugd...@yahoo.com.au changed: What|Removed |Added Version|2.012 |1.020 Summary|ICE(cod1.c) using static|ICE(e2ir.c) using static |array as AA key |array as AA key --- Comment #2 from Don clugd...@yahoo.com.au 2009-09-13 11:37:06 PDT --- The original version for this bug report was 2.012, and in both D1 and D2, it used to ICE in cod1.c. (Test cases also ICEs in 1.020). It was fixed in DMD2.026, but not listed in the changelog and not fixed in D1. In recent versions of D1, it ICEs in e2ir.c. I've changed compiler version and title accordingly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
