Re: Precise GC

On Apr 7, 2012, at 6:56 PM, Walter Bright wrote: > Of course, many of us have been thinking about this for a looong time, and > what is the best way to go about it. The usual technique is for the compiler > to emit some sort of table for each TypeInfo giving the layout of the object, > i.e. wh

Re: std.benchmark ready for review. Manager sought after

On Sunday, 8 April 2012 at 05:41:11 UTC, Andrei Alexandrescu wrote: 3) "benchmark_relative_file read" should be replaced with a language construct. E.g. a function call like relativeBenchmark("file read"), or an enum value like getopt's. No can do. Need a function name-based convention so we

Re: Custom attributes (again)

I don't want this thread to disappear. The ideas presented here have common basic features among the nice-to-haves. 1. Attributes add meta data baggage to a symbol 2. This meta data is thought of as a read-only hash (has, get, iterate) 3. Can be queried at compile-time 4. The syntax is concise (i

Re: a pretty exciting result for parallel D lang rmd following defrag by name

On Sunday, 8 April 2012 at 01:18:49 UTC, Jay Norwood wrote: in it. Same 3.7 second delete. I'll have to analyze what is happening, but this is a huge improvement. If it is just the sequential LCN order of the operations, it may be that I can just pre-sort the delete operations by the file

Re: std.benchmark ready for review. Manager sought after

Le 08/04/2012 05:25, Andrei Alexandrescu a écrit : > Hello, > > > I finally found the time to complete std.benchmark. I got to a very > simple API design, starting where I like it: one line of code. > > Code is in the form of a pull request at > https://github.com/D-Programming-Language/phobos/p

Re: Precise GC

On 04/08/2012 03:56 AM, Walter Bright wrote: Of course, many of us have been thinking about this for a looong time, and what is the best way to go about it. The usual technique is for the compiler to emit some sort of table for each TypeInfo giving the layout of the object, i.e. where the pointer

Shared library in D on Linux

I am still testing which setup gives me reliable shared D libraries which can be used from C. Here is my latest test: * test.d: import std.stdio; extern (C) { void hiD() { writeln("hi from D lib"); } } * main.c #include #include #include void main() { void (*hiD)(void); void

Re: Precise GC

On 04/08/2012 10:45 AM, Timon Gehr wrote: That actually sounds like a pretty awesome idea. Make sure that the compiler does not actually rely on the fact that the template generates a function. The design should include the possibility of just generating tables. It all should be completely tr

Re: D projects list

Am Fri, 6 Apr 2012 14:52:38 -0400 schrieb "Nick Sabalausky" : > "H. S. Teoh" wrote in message > news:mailman.1417.1333721195.4860.digitalmar...@puremagic.com... > > On Fri, Apr 06, 2012 at 12:34:09PM +0400, Denis Shelomovskij wrote: > >> And adobe Flash of course should also die. > > > > +1. It

Re: Issue with module destructor order

Created bug ticket: http://d.puremagic.com/issues/show_bug.cgi?id=7855 -- Kind Regards Benjamin Thaut

readonly storage class

While typing D code I usually come across the problem that neither const nor immutable describe the usage pattern of the memory I'm currently working on 100%. Sometimes I have immutable data that has been shared among threads that I want to pass to a function. Then I have some const data that I

Re: Discussion on Go and D

On 4/7/12, Andrei Alexandrescu wrote: > 3. The ability to dispose of memory will disappear along with the delete > keyword. Pull this and hopefully that myth will come to an end: https://github.com/D-Programming-Language/d-programming-language.org/pull/112

Re: Precise GC

On 04/08/2012 10:45 AM, Timon Gehr wrote: That actually sounds like a pretty awesome idea. I understand that the stack will still have to be scanned conservatively, but how does the scheme deal with closures?

Re: a pretty exciting result for parallel D lang rmd following defrag by name

Le 08/04/2012 09:34, Jay Norwood a écrit : > On Sunday, 8 April 2012 at 01:18:49 UTC, Jay Norwood wrote: >> in it. Same 3.7 second delete. I'll have to analyze what is >> happening, but this is a huge improvement. If it is just the >> sequential LCN order of the operations, it may be that I ca

Re: readonly storage class

On Sunday, April 08, 2012 11:16:40 Benjamin Thaut wrote: > While typing D code I usually come across the problem that neither const > nor immutable describe the usage pattern of the memory I'm currently > working on 100%. Sometimes I have immutable data that has been shared > among threads that I w

Re: readonly storage class

On 04/08/2012 11:16 AM, Benjamin Thaut wrote: While typing D code I usually come across the problem that neither const nor immutable describe the usage pattern of the memory I'm currently working on 100%. Sometimes I have immutable data that has been shared among threads that I want to pass to a

Re: Small Buffer Optimization for string and friends

On 4/8/12, Andrei Alexandrescu wrote: > essentially making them templates I just hope that doesn't cause: 1) Awful template errors 2) Slower build times 3) More ICEs

Re: Precise GC

On 4/8/2012 2:21 AM, Timon Gehr wrote: On 04/08/2012 10:45 AM, Timon Gehr wrote: That actually sounds like a pretty awesome idea. I understand that the stack will still have to be scanned conservatively, but how does the scheme deal with closures? For now, just treat them conservatively.

Re: readonly storage class

Am 08.04.2012 11:28, schrieb Jonathan M Davis: On Sunday, April 08, 2012 11:16:40 Benjamin Thaut wrote: While typing D code I usually come across the problem that neither const nor immutable describe the usage pattern of the memory I'm currently working on 100%. Sometimes I have immutable data t

Re: Precise GC

On 8 April 2012 11:56, Timon Gehr wrote: > On 04/08/2012 10:45 AM, Timon Gehr wrote: > >> That actually sounds like a pretty awesome idea. >> > > Make sure that the compiler does not actually rely on the fact that the > template generates a function. The design should include the possibility of >

Re: readonly storage class

On Sunday, April 08, 2012 11:39:03 Benjamin Thaut wrote: > I'll come up with a example. > But if what you say is true, why is immutable not implicitly convertible > to const? It _is_ implictly convertible to const. - Jonathan M Davis

Re: Small Buffer Optimization for string and friends

On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu wrote: Walter and I discussed today about using the small string optimization in string and other arrays of immutable small objects. On 64 bit machines, string occupies 16 bytes. We could use the first byte as discriminator, which m

Re: readonly storage class

On Sun, 08 Apr 2012 11:39:03 +0200, Benjamin Thaut wrote: Am 08.04.2012 11:28, schrieb Jonathan M Davis: On Sunday, April 08, 2012 11:16:40 Benjamin Thaut wrote: While typing D code I usually come across the problem that neither const nor immutable describe the usage pattern of the memory

Re: Discussion on Go and D

On 4/8/2012 12:04 AM, Timon Gehr wrote: On 04/07/2012 04:43 PM, Rainer Schuetze wrote: On 4/7/2012 8:24 AM, Dmitry Olshansky wrote: On 07.04.2012 2:08, Rainer Schuetze wrote: On 4/6/2012 8:01 PM, Walter Bright wrote: On 4/6/2012 10:37 AM, Rainer Schuetze wrote: I hope there is somethin

Re: Small Buffer Optimization for string and friends

On 8 April 2012 12:46, Vladimir Panteleev wrote: > On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu wrote: > >> Walter and I discussed today about using the small string optimization in >> string and other arrays of immutable small objects. >> >> On 64 bit machines, string occupies 16

Re: Small Buffer Optimization for string and friends

On Sunday, 8 April 2012 at 09:46:28 UTC, Vladimir Panteleev wrote: On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu wrote: Walter and I discussed today about using the small string optimization in string and other arrays of immutable small objects. On 64 bit machines, string occup

Re: Precise GC

On 4/8/2012 11:21 AM, Timon Gehr wrote: On 04/08/2012 10:45 AM, Timon Gehr wrote: That actually sounds like a pretty awesome idea. I understand that the stack will still have to be scanned conservatively, but how does the scheme deal with closures? I guess the compiler should generate an (

Re: Custom attributes (again)

On 2012-04-08 09:27, Marco Leise wrote: I don't want this thread to disappear. The ideas presented here have common basic features among the nice-to-haves. For these to work it would require: - user annotations to functions/methods/structs/classes - only CTFE support (as annotations don't cha

Re: std.benchmark ready for review. Manager sought after

Andrei Alexandrescu wrote: I finally found the time to complete std.benchmark. I got to a very simple API design, starting where I like it: one line of code. Code is in the form of a pull request at https://github.com/D-Programming-Language/phobos/pull/529. (There's some noise in there caused by

Re: Shared library in D on Linux

On 2012-04-08 10:45, "Timo Westkämper" " wrote: I am still testing which setup gives me reliable shared D libraries which can be used from C. Here is my latest test: * test.d: import std.stdio; extern (C) { void hiD() { writeln("hi from D lib"); } } * main.c #include #include #include void

Re: Small Buffer Optimization for string and friends

On 2012-04-08 07:56, Andrei Alexandrescu wrote: For this to happen, we need to start an effort of migrating built-in arrays into runtime, essentially making them templates that the compiler lowers to. So I have two questions: Just don't make the same mistake as with AA. -- /Jacob Carlborg

Re: custom attribute proposal (yeah, another one)

Am Fri, 06 Apr 2012 16:53:56 +0200 schrieb Timon Gehr : > On 04/06/2012 04:23 PM, Steven Schveighoffer wrote: > > Why should we be restricted to only structs? Or any type for that matter? > > > > A restriction to only structs is not a restriction because structs can > have arbitrary field types.

Re: readonly storage class

Benjamin Thaut wrote: The only thing the function cares about is, that it will not change the data passed to it. It would be kind of nice to have a thrid storage class "readonly". Const is really a "readonly" view of data. I think that immutable should be named const, and const should be named

A modest proposal: eliminate template code bloat

I think it's been ages since I meant to ask why nobody (as in compiler vendors) does what I think is rather simple optimization. In the short term the plan is to introduce a "link-time" flavored optimization at code generation or (better) link step. For simplicity let's assume compiler does a

Re: Precise GC

On 08-04-2012 12:07, Rainer Schuetze wrote: On 4/8/2012 11:21 AM, Timon Gehr wrote: On 04/08/2012 10:45 AM, Timon Gehr wrote: That actually sounds like a pretty awesome idea. I understand that the stack will still have to be scanned conservatively, but how does the scheme deal with closures

Re: readonly storage class

Piotr Szturmaj wrote: If you need a function that don't change data just mark parameters as ^ doesn't

Re: Precise GC

On 08-04-2012 11:42, Manu wrote: On 8 April 2012 11:56, Timon Gehr mailto:timon.g...@gmx.ch>> wrote: On 04/08/2012 10:45 AM, Timon Gehr wrote: That actually sounds like a pretty awesome idea. Make sure that the compiler does not actually rely on the fact that the template

Re: Issue with module destructor order

On Mar 26, 2012 5:11 AM, "Benjamin Thaut" wrote: > Is this intended behaviour or is this a bug? I assume this happens because of the mixin template and the public import. > I'm using dmd 2.058. > > -- > Kind Regards > Benjamin Thaut I don't think the order of destructors is defined. There would b

Re: Custom attributes (again)

Am Sun, 08 Apr 2012 12:44:17 +0200 schrieb Jacob Carlborg : > On 2012-04-08 09:27, Marco Leise wrote: > > I don't want this thread to disappear. The ideas presented here have common > > basic features among the nice-to-haves. > > > For these to work it would require: > > - user annotations to fu

Re: A modest proposal: eliminate template code bloat

Am Sun, 08 Apr 2012 15:01:56 +0400 schrieb Dmitry Olshansky : > I think it's been ages since I meant to ask why nobody (as in compiler > vendors) does what I think is rather simple optimization. > > In the short term the plan is to introduce a "link-time" flavored > optimization at code generat

Re: Issue with module destructor order

On 04/08/2012 02:14 PM, Kevin Cox wrote: On Mar 26, 2012 5:11 AM, "Benjamin Thaut" mailto:c...@benjamin-thaut.de>> wrote: > Is this intended behaviour or is this a bug? I assume this happens because of the mixin template and the public import. > I'm using dmd 2.058. > > -- > Kind Regards >

Re: Small Buffer Optimization for string and friends

On Sun, Apr 08, 2012 at 12:56:38AM -0500, Andrei Alexandrescu wrote: [...] > 1. What happened to the new hash project? We need to take that to > completion. [...] Sorry, I've been busy at work and haven't had too much free time to work on it. The current code is available on github: http

Re: Small Buffer Optimization for string and friends

On Sunday, 8 April 2012 at 13:53:07 UTC, H. S. Teoh wrote: On Sun, Apr 08, 2012 at 12:56:38AM -0500, Andrei Alexandrescu wrote: [...] 1. What happened to the new hash project? We need to take that to completion. [...] Sorry, I've been busy at work and haven't had too much free time to work

Re: A modest proposal: eliminate template code bloat

On Sun, Apr 08, 2012 at 03:01:56PM +0400, Dmitry Olshansky wrote: > I think it's been ages since I meant to ask why nobody (as in > compiler vendors) does what I think is rather simple optimization. > > In the short term the plan is to introduce a "link-time" flavored > optimization at code genera

Re: A modest proposal: eliminate template code bloat

On 04/08/12 13:01, Dmitry Olshansky wrote: > 3. After any function was generated compiler checks an entry in the duplicate > table that matches size, followed by matching checksum and only then (if > required) doing a straight memcmp. If it happens that there is a match > compiler just throws ge

Re: Small Buffer Optimization for string and friends

On Sun, Apr 08, 2012 at 04:11:10PM +0200, Tove wrote: > On Sunday, 8 April 2012 at 13:53:07 UTC, H. S. Teoh wrote: > >On Sun, Apr 08, 2012 at 12:56:38AM -0500, Andrei Alexandrescu > >wrote: > >[...] > >>1. What happened to the new hash project? We need to take that to > >>completion. > >[...] [...]

Re: Small Buffer Optimization for string and friends

On 8 April 2012 12:54, Manu wrote: > On 8 April 2012 12:46, Vladimir Panteleev wrote: > >> On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu wrote: >> >>> Walter and I discussed today about using the small string optimization >>> in string and other arrays of immutable small objects. >

Re: Small Buffer Optimization for string and friends

On 4/8/12 1:33 AM, Daniel Murphy wrote: - This has been a disaster for AAs Making them "magic" has been the problem. We must revert that. - Is it worth doing for 32 bit? Probably not. - Would generate false pointers Fair point but we're also moving to precise collection :o). - Run-tim

Re: std.benchmark ready for review. Manager sought after

On 4/8/12 2:02 AM, Vladimir Panteleev wrote: The "benchmark_relative_" prefix makes sense for function names (for scheduleForBenchmarking), but not so much for string literals for benchmark names. The string literal "benchmark_relative_file read" looks like the words "benchmark relative file" are

Re: std.benchmark ready for review. Manager sought after

On 4/8/12 3:16 AM, Somedude wrote: Like it. Would it be a good idea to add a column with an average memory used ? Interesting idea. I saw http://stackoverflow.com/questions/1674652/c-c-memory-usage-api-in-linux-windows and it looks like it's not an easy problem. Should we make this part of t

Re: Discussion on Go and D

On 4/8/12 4:20 AM, Andrej Mitrovic wrote: On 4/7/12, Andrei Alexandrescu wrote: 3. The ability to dispose of memory will disappear along with the delete keyword. Pull this and hopefully that myth will come to an end: https://github.com/D-Programming-Language/d-programming-language.org/pull/11

Re: Small Buffer Optimization for string and friends

On 4/8/12 4:46 AM, Vladimir Panteleev wrote: On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu wrote: Walter and I discussed today about using the small string optimization in string and other arrays of immutable small objects. On 64 bit machines, string occupies 16 bytes. We could u

Re: Small Buffer Optimization for string and friends

On 4/8/12 4:30 AM, Andrej Mitrovic wrote: On 4/8/12, Andrei Alexandrescu wrote: essentially making them templates I just hope that doesn't cause: 1) Awful template errors 2) Slower build times 3) More ICEs Walter and I agree that relying on sheer D for instead of compiler-generated magic (

Re: Shared library in D on Linux

On 04/08/2012 03:45 AM, "Timo Westkämper" " wrote: extern(C) { void gc_init(); void gc_term(); void _init() { gc_init(); } void _fini() { gc_term(); } } I think you want rt_init and rt_term here.

Re: Small Buffer Optimization for string and friends

On 4/8/12 4:55 AM, Vladimir Panteleev wrote: On Sunday, 8 April 2012 at 09:46:28 UTC, Vladimir Panteleev wrote: On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu wrote: Walter and I discussed today about using the small string optimization in string and other arrays of immutable smal

Re: Small Buffer Optimization for string and friends

On 4/8/12 9:49 AM, Andrei Alexandrescu wrote: On 4/8/12 4:46 AM, Vladimir Panteleev wrote: On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu wrote: Walter and I discussed today about using the small string optimization in string and other arrays of immutable small objects. On 64 bit

Re: Small Buffer Optimization for string and friends

On 4/8/12 5:45 AM, Jacob Carlborg wrote: On 2012-04-08 07:56, Andrei Alexandrescu wrote: For this to happen, we need to start an effort of migrating built-in arrays into runtime, essentially making them templates that the compiler lowers to. So I have two questions: Just don't make the same m

Re: Small Buffer Optimization for string and friends

On 4/8/12 4:54 AM, Manu wrote: On 8 April 2012 12:46, Vladimir Panteleev mailto:vladi...@thecybershadow.net>> wrote: On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu wrote: Walter and I discussed today about using the small string optimization in string and other

Re: std.benchmark ready for review. Manager sought after

On 4/8/12 5:46 AM, Piotr Szturmaj wrote: Andrei Alexandrescu wrote: I finally found the time to complete std.benchmark. I got to a very simple API design, starting where I like it: one line of code. Code is in the form of a pull request at https://github.com/D-Programming-Language/phobos/pull/5

Re: Small Buffer Optimization for string and friends

On 2012-04-08 05:56:38 +, Andrei Alexandrescu said: Walter and I discussed today about using the small string optimization in string and other arrays of immutable small objects. On 64 bit machines, string occupies 16 bytes. We could use the first byte as discriminator, which means that

Re: Small Buffer Optimization for string and friends

On 8 April 2012 17:52, Andrei Alexandrescu wrote: > On 4/8/12 4:54 AM, Manu wrote: > >> On 8 April 2012 12:46, Vladimir Panteleev > > >> wrote: >> >>On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu wrote: >> >>Walter and I discussed to

Re: Small Buffer Optimization for string and friends

On 4/8/12 8:54 AM, H. S. Teoh wrote: - Qualified keys not fully working: the current code has a few corner cases that don't work with shared/immutable/inout keys. One major roadblock is how to implement this: alias someType T; inout(T) myFunc(inout(T) arg, ...) {

Re: Small Buffer Optimization for string and friends

On 4/8/12 8:54 AM, H. S. Teoh wrote: Sorry, I've been busy at work and haven't had too much free time to work on it. The current code is available on github: https://github.com/quickfur/New-AA-implementation Thanks for the update! Let me reiterate this is important work for many reas

Re: Small Buffer Optimization for string and friends

On 4/8/12 9:59 AM, Michel Fortin wrote: But as soon as you take a pointer to that string, you break the immutability guaranty: immutable(char)[] s = "abcd"; immutable(char)* p = s.ptr; s = "defg"; // assigns to where? Taking .ptr will engender a copy. A small regression will be that address o

Re: Small Buffer Optimization for string and friends

On 4/8/12 10:03 AM, Manu wrote: 29 bits? ...not 31? Sorry, 31 indeed. How does this implementation actually work? On 32/64 bits, and little/big endian? I can only imagine it working with a carefully placed 1 bit. bit-0 of the size on little endian, and bit-31 of the size on big endian. That s

Re: Small Buffer Optimization for string and friends

On 4/8/12 9:26 AM, Manu wrote: Is it realistic that anyone can actually use raw d-string's in an app that performs a lot of string manipulation? Yes. I bet most people end up with a custom string class anyway... That does happen, but much more rarely than one might think. Who's written a

Re: A modest proposal: eliminate template code bloat

On 08.04.2012 18:21, Artur Skawina wrote: On 04/08/12 13:01, Dmitry Olshansky wrote: 3. After any function was generated compiler checks an entry in the duplicate table that matches size, followed by matching checksum and only then (if required) doing a straight memcmp. If it happens that ther

Re: Small Buffer Optimization for string and friends

On 2012-04-08 16:54, Andrei Alexandrescu wrote: On 4/8/12 5:45 AM, Jacob Carlborg wrote: On 2012-04-08 07:56, Andrei Alexandrescu wrote: For this to happen, we need to start an effort of migrating built-in arrays into runtime, essentially making them templates that the compiler lowers to. So I

Re: std.benchmark ready for review. Manager sought after

On 08.04.2012 12:16, Somedude wrote: [snip] Like it. Would it be a good idea to add a column with an average memory used ? In general it's next to impossible and/or entirely OS-specific. What can be done I think is adding a query function to GC interface that returns amount of RAM currently a

Re: Small Buffer Optimization for string and friends

On 2012-04-08 15:06:13 +, Andrei Alexandrescu said: On 4/8/12 9:59 AM, Michel Fortin wrote: But as soon as you take a pointer to that string, you break the immutability guaranty: immutable(char)[] s = "abcd"; immutable(char)* p = s.ptr; s = "defg"; // assigns to where? Taking .ptr will

Re: Shared library in D on Linux

I'm interessting in the same stuff. I've a question to _tlsend and _tlsstart. What are they used for? My disputable presumption was that they point to the begin of TLS segment. What is _deh_begin and _deh_end used for?

Re: Small Buffer Optimization for string and friends

On 4/8/12 10:48 AM, Michel Fortin wrote: On 2012-04-08 15:06:13 +, Andrei Alexandrescu said: On 4/8/12 9:59 AM, Michel Fortin wrote: But as soon as you take a pointer to that string, you break the immutability guaranty: immutable(char)[] s = "abcd"; immutable(char)* p = s.ptr; s = "defg"

Re: A modest proposal: eliminate template code bloat

On 04/08/12 17:20, Dmitry Olshansky wrote: > On 08.04.2012 18:21, Artur Skawina wrote: >> On 04/08/12 13:01, Dmitry Olshansky wrote: >>> 3. After any function was generated compiler checks an entry in the >>> duplicate table that matches size, followed by matching checksum and only >>> then (if r

Re: A modest proposal: eliminate template code bloat

Am Sun, 8 Apr 2012 07:18:26 -0700 schrieb "H. S. Teoh" : > We'd have to make sure the checksum doesn't end up in the final > executable though, otherwise the bloat may negate any gains we've made. Executables (and object files) are made up mostly of sections, some of which are 'special cased' to

Re: readonly storage class

Am 08.04.2012 11:49, schrieb Simen Kjaeraas: On Sun, 08 Apr 2012 11:39:03 +0200, Benjamin Thaut wrote: Am 08.04.2012 11:28, schrieb Jonathan M Davis: On Sunday, April 08, 2012 11:16:40 Benjamin Thaut wrote: While typing D code I usually come across the problem that neither const nor immutabl

Re: a pretty exciting result for parallel D lang rmd following defrag by name

On Sunday, 8 April 2012 at 09:21:43 UTC, Somedude wrote: Hi, You seem to have done a pretty good job with your parallel unzip. Have you tried a parallel zip as well ? Do you think you could include this in std.zip when you're done ? I'm going to do a parallel zip as well. There is already

Re: A modest proposal: eliminate template code bloat

Am Sun, 08 Apr 2012 16:21:14 +0200 schrieb Artur Skawina : > On 04/08/12 13:01, Dmitry Olshansky wrote: > > 3. After any function was generated compiler checks an entry in the > > duplicate table that matches size, followed by matching checksum and only > > then (if required) doing a straight me

Re: A modest proposal: eliminate template code bloat

On 4/8/12 10:59 AM, Artur Skawina wrote: On 04/08/12 17:20, Dmitry Olshansky wrote: On 08.04.2012 18:21, Artur Skawina wrote: On 04/08/12 13:01, Dmitry Olshansky wrote: 3. After any function was generated compiler checks an entry in the duplicate table that matches size, followed by matching

Re: std.benchmark ready for review. Manager sought after

Am Sun, 08 Apr 2012 09:35:14 -0500 schrieb Andrei Alexandrescu : > On 4/8/12 3:16 AM, Somedude wrote: > > Like it. Would it be a good idea to add a column with an average memory > > used ? > > Interesting idea. I saw > http://stackoverflow.com/questions/1674652/c-c-memory-usage-api-in-linux-wind

Re: A modest proposal: eliminate template code bloat

On 08.04.2012 19:59, Artur Skawina wrote: On 04/08/12 17:20, Dmitry Olshansky wrote: On 08.04.2012 18:21, Artur Skawina wrote: On 04/08/12 13:01, Dmitry Olshansky wrote: 3. After any function was generated compiler checks an entry in the duplicate table that matches size, followed by matching

Re: A modest proposal: eliminate template code bloat

On 08.04.2012 18:18, H. S. Teoh wrote: [snip] 1. Every time a function is generated (or pretty much any symbol) not only a size calculated but also a checksum* of it's data. (If we go for link-time optimization we should find a place to stick it to in the object file) We'd have to make sure th

Re: A modest proposal: eliminate template code bloat

On 08.04.2012 16:37, Marco Leise wrote: [snip] Template bloat could be especially important to 'fix' on embedded systems. I think I this idea largely formed years ago when I was working with c++ on 8bit micros. You won't believe the amount of code size one can save by using one separate gener

Re: std.benchmark ready for review. Manager sought after

Very good but minimum isn't a best guess. Personally I (and there will be a lot of such maniacs I suppose) will think that this (minimum) time can be significantly smaller than average time. So a parameter (probably with a default value) should be added. Something like enum of flags telling wh

Re: Small Buffer Optimization for string and friends

On 4/8/2012 7:53 AM, Andrei Alexandrescu wrote: Once anyone asks for .ptr a conservative copy will be made. That could get expensive. You cannot just point into the small string part, because that may only exist temporarily on the stack. There are some pathological cases for this.

Re: Small Buffer Optimization for string and friends

On Sun, Apr 08, 2012 at 05:35:50PM +0200, Jacob Carlborg wrote: > On 2012-04-08 16:54, Andrei Alexandrescu wrote: > >On 4/8/12 5:45 AM, Jacob Carlborg wrote: [...] > >>Just don't make the same mistake as with AA. > > > >The mistake with AAs was done long ago, but it was forced as AAs > >predated te

Re: readonly storage class

On 04/08/2012 06:09 PM, Benjamin Thaut wrote: Am 08.04.2012 11:49, schrieb Simen Kjaeraas: On Sun, 08 Apr 2012 11:39:03 +0200, Benjamin Thaut wrote: I'll come up with a example. But if what you say is true, why is immutable not implicitly convertible to const? It is. Thanks, then this is a

Re: Small Buffer Optimization for string and friends

On Sun, Apr 08, 2012 at 10:00:37AM -0500, Andrei Alexandrescu wrote: > On 4/8/12 8:54 AM, H. S. Teoh wrote: > >Sorry, I've been busy at work and haven't had too much free time to work > >on it. The current code is available on github: > > > > https://github.com/quickfur/New-AA-implementation >

Re: Small Buffer Optimization for string and friends

On 4/8/12 12:05 PM, Walter Bright wrote: On 4/8/2012 7:53 AM, Andrei Alexandrescu wrote: Once anyone asks for .ptr a conservative copy will be made. That could get expensive. You cannot just point into the small string part, because that may only exist temporarily on the stack. There are some

Re: A modest proposal: eliminate template code bloat

On Sun, Apr 08, 2012 at 08:45:19PM +0400, Dmitry Olshansky wrote: > On 08.04.2012 18:18, H. S. Teoh wrote: > [snip] > >We'd have to make sure the checksum doesn't end up in the final > >executable though, otherwise the bloat may negate any gains we've > >made. > > Easy the symbol size is in object

Re: Discussion on Go and D

On 4/6/2012 9:07 AM, Andrei Alexandrescu wrote: A few more samples of people's perception of the two languages: http://news.ycombinator.com/item?id=3805302 At least we don't have this issue: http://news.ycombinator.com/item?id=3814020 The D gc allocates smallish "chunks" as required, not one

Re: Discussion on Go and D

On Sun, Apr 08, 2012 at 09:42:42AM -0500, Andrei Alexandrescu wrote: > On 4/8/12 4:20 AM, Andrej Mitrovic wrote: > >On 4/7/12, Andrei Alexandrescu wrote: > >>3. The ability to dispose of memory will disappear along with the > >>delete keyword. > > > >Pull this and hopefully that myth will come to

Re: readonly storage class

On Sun, Apr 08, 2012 at 06:09:48PM +0200, Benjamin Thaut wrote: [...] > Thanks, then this is a misunderstanding on my side, and this topic is > irrelevant. But what about calling const methods on immutable objects? [...] Basically, the way const/immutable works is: const

Re: std.benchmark ready for review. Manager sought after

On 4/8/12 11:59 AM, Denis Shelomovskij wrote: Very good but minimum isn't a best guess. Personally I (and there will be a lot of such maniacs I suppose) will think that this (minimum) time can be significantly smaller than average time. I've analyzed this quite a bit at work and the average and

Re: A modest proposal: eliminate template code bloat

Am Sun, 08 Apr 2012 20:58:15 +0400 schrieb Dmitry Olshansky : > On 08.04.2012 16:37, Marco Leise wrote: > [snip] > > Template bloat could be especially important to 'fix' on embedded systems. > > I think I this idea largely formed years ago when I was working with c++ > on 8bit micros. You won't

Re: std.benchmark ready for review. Manager sought after

On 08.04.2012 20:59, Denis Shelomovskij wrote: Very good but minimum isn't a best guess. Personally I (and there will be a lot of such maniacs I suppose) will think that this (minimum) time can be significantly smaller than average time. Prime example is networking. So a parameter (probably

Re: std.benchmark ready for review. Manager sought after

On 4/8/12 12:35 PM, Dmitry Olshansky wrote: Another cool addition IMHO would be parametric benchmarks, so there is a function and a set of parameters (one parameter is fine too) to benchmark on. It makes that much more sense with graphs as algorithm profile plotted for various inputs (sizes) can

Re: Shared library in D on Linux

On Sunday, 8 April 2012 at 14:52:55 UTC, Ellery Newcomer wrote: On 04/08/2012 03:45 AM, "Timo Westkämper" " wrote: extern(C) { void gc_init(); void gc_term(); void _init() { gc_init(); } void _fini() { gc_term(); } } I think you want rt_init and rt_term here. I got now the simple exampl

Documentation improvements

Hi everyone, I decided to give D a try yesterday and had quite some trouble with the documentation. I want to help improve the docs on dlang.org. Here are some ideas. The top links in the left menu really should documentation. Most people don't care about Acknowledgements, the Sitemap, D1,

Re: Shared library in D on Linux

On 2012-04-08 17:53, mta`chrono wrote: I'm interessting in the same stuff. I've a question to _tlsend and _tlsstart. What are they used for? My disputable presumption was that they point to the begin of TLS segment. Yes, exactly, the start and end of the TLS segment. What is _deh_begin and _d

Re: GSoC 2012 Proposal: Continued Work on a D Linear Algebra library (SciD - std.linalg)

On Tue, Apr 3, 2012 at 6:20 AM, Cristi Cobzarenco wrote: > > The point of these is to have light-weight element wise operation support. > It's true that in theory the built-in arrays do this. However, this library > is built on top BLAS/LAPACK, which means operations on large matrices will > be fa

  1   2   >