Re: Should binary sharing be done using Mixin Template?
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.306.1305975846.14074.digitalmar...@puremagic.com... Templates are completely different from generics. Generics are compile-time artifacts only and have no effect on the final binary. Templates, on the other hand, are generated for each type that they're instantiated with. They are code generation, pure and simple. And since each and every instantiation could be very different depending on what was done with static if and other compile- time stuff which can affect code generation. So, if you had a LinkedListAccount and a LinkedListstring, their internal implementation could be completely different if the writer of LinkedList thought that it was appropriate to do so for whatever reason. Cant the compiler simply do a bitwise compare of all versions of a given template function/method, and remove any that have duplicate code? I mean actually compare the generated asm code.
Re: Removing The Global GC Lock: Largest Plausible Number of Threads?
dsimcha dsim...@yahoo.com wrote in message news:iqfn3l$p2p$1...@digitalmars.com... I'm thinking about ways to remove the global lock from the garbage collector for most small allocations. I'm basically thinking of making the free lists thread local. If you use lock free free lists you dont need one for every thread, you only need enough to reduce contention on the free lists, which in my experience is about 1x to 2x the number of cores you have.
Re: Removing The Global GC Lock: Largest Plausible Number of Threads?
dsimcha dsim...@yahoo.com wrote in message news:iqj8ba$18sc$1...@digitalmars.com... On 5/13/2011 6:12 AM, Kagamin wrote: dsimcha Wrote: I'm thinking about ways to remove the global lock from the garbage collector for most small allocations. I'm basically thinking of making the free lists thread local. http://www.liblfds.org/ ? Surprisingly, lock-free free lists wouldn't solve the problem, since the GC flag bookkeeping would still require locking unless it is completely rewritten. If the flag needs to be atomicaly updated and thread local free lists solve that problem yet global lock free free lists dont, the implication is that the flag is only ever accessed from the one thread. And that implies that memory cant be allocated in one thread and freed in another?
Re: Floating Point + Threads?
Sean Kelly s...@invisibleduck.org wrote in message
news:mailman.3597.1303316625.4748.digitalmar...@puremagic.com...
On Apr 20, 2011, at 5:06 AM, Don wrote:
Sean Kelly wrote:
On Apr 16, 2011, at 1:02 PM, Robert Jacques wrote:
On Sat, 16 Apr 2011 15:32:12 -0400, Walter Bright
newshou...@digitalmars.com wrote:
The dmd startup code (actually the C startup code) does an fninit. I
never thought about new thread starts. So, yeah, druntime should do an
fninit on thread creation.
The documentation I've found on fninit seems to indicate it defaults to
64-bit precision, which means that by default we aren't seeing the
benefit of D's reals. I'd much prefer 80-bit precision by default.
There is no option to set 80-bit precision via the FPU control word.
??? Yes there is.
enum PrecisionControl : short {
PRECISION80 = 0x300,
PRECISION64 = 0x200,
PRECISION32 = 0x000
};
So has Intel deprecated 80-bit FPU support? Why do the docs for this say
that 64-bit
is the highest precision? And more importantly, does this mean that we
should be setting
the PC field explicitly instead of relying on fninit? The docs say that
fninit initializes to
64-bit precision. Or is that inaccurate as well?=
You misread the docs, it's talking about precision which is just the size of
the mantisa, not the actual full size of the floating point data. IE...
80 float = 64 bit precision
64 float = 53 bit precision
32 float = 24 bit precision
Re: Floating Point + Threads?
dsimcha dsim...@yahoo.com wrote in message news:iocalv$2h58$1...@digitalmars.com... Output: Rounding mode: 0 0.7853986633972191094 Rounding mode: 0 0.7853986633972437348 Could be something somewhere is getting truncated from real to double, which would mean 12 fewer bits of mantisa. Maybe the FPU is set to lower precision in one of the threads?
Re: inlining or not inlining...
Walter Bright newshou...@digitalmars.com wrote in message news:ij41q1$1j1q$2...@digitalmars.com... bearophile wrote: While in isolation that's a good idea, how far should it be taken? Should the compiler emit information on which variables wound up in which registers, and why? What about other of the myriad of compiler optimizations? Inlining is an important optimization, so give this information to the programmer is a good start. Register allocation is far more important than inlining. Why not give information about why a variable was not enregistered? Whether either should be left up to the compiler should be down the merits of actually doing so, not on whether the other one is or not. Nobody wants to be able to specify register allocation. At least ive not seen anyone ask for it. So thats an easy decision. It's a feature nobody would use even if it were included. Inlining is completly different. Lots of people want the ability to control it, or at least to be able to be notified when it doesnt happen. You say look at the asm output? So everytime the compiler gets updated, or somthing changes, we dig through how much source/dissambly to check everything is still getting inlined? Or you say that the compiler can make better decision than the programmer? Maybe it can most of the time but even very mature compilers still spit out awful code sometimes. I thought D was supposed to be a pragmatic language? Well maybe that pragmatism should extend to realizing that compilers dont always get it right.
Re: align(n) not working as expected
Robert Jacques sandf...@jhu.edu wrote in message news:op.voeybap626s...@sandford... On Tue, 28 Dec 2010 00:32:37 -0700, %u wfunct...@hotmail.com wrote: As per the docs, align behaves in the manner of the companion C++ compile. DMC only defines align(1) and align(4), so they're the only two that work. So this isn't a bug per say, but more than one of us has asked for align(8)/align(16) support. (or at least a compile time warning). But there's several technical/performance issues with maintaining alignment different from the underlying OS. I'd also recommend D.learn for questions like these. The only issue is with stack variables. There's no reason not to have align(8) and align(16) for members. Heap alignment can be handled with a custom allocator. It's just retarded to not have align(16) for members and yet have support for SSE asm instructions. It's like telling someone yes the car has steering, but you have to use these two pieces of rope because we couldnt work out / afford power steering. The point being you could have put in un-powered steering for now at least.
Re: Basic coding style
bearophile bearophileh...@lycos.com wrote in message news:icdnn4$2cn...@digitalmars.com... I have four or five times tried to explain why coding standards are important for the development of the D community And them there stupid people just wont listen to ya. Thats mighty unreasonable of them, you being president of the world an all.
Re: More Clang diagnostic
Michel Fortin michel.for...@michelf.com wrote in message news:ia5e1v$22j...@digitalmars.com... On 2010-10-25 21:57:54 -0400, Walter Bright newshou...@digitalmars.com said: bearophile wrote: Walter: It's the very next token. There's nothing wrong with the message. In that case I prefer the error message to refer to the line where the semicolon is absent. I may ask a poll to other D users to see if they agree with me or not on this. It's of very questionable value when you consider that D is not a line oriented language at all. There is no correct placement of ; in a sequence of whitespace. It's much faster to fix a problem when the IDE sends you right where you need to type. One of my favourite features of the Delphi IDE was that when you compiled it would take you to the exact palce of the first error it found. And because the compile times were so fast you could just press or click compile, fix the typo / bug, press / click it again. So you could use the compile button as a next bug to fix button, and work your way through them very quickly.
Re: New slides about Go
Walter Bright newshou...@digitalmars.com wrote in message news:i98frv$1dm...@digitalmars.com... bearophile wrote: Nick Sabalausky: Then you're wasting cycles every iteration (by doing an extra addition and maybe an extra shift or even multiplication depending on T: Ie, (cast(ubyte*)myArray.ptr) + i * T.sizeof). That was a pretty common inner-loop optimization back in my C days. With D sometimes array-based code is faster than pointer-based. With LDC they are usually equally efficient. ??? This makes no sense. The (ptr+i*T.sizeof) is an addressing mode on the x86, and comes at ZERO cost. As long as T.sizeof is either 1, 2, 4, or 8 bytes.
Re: duck!
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:i9ae2n$k9...@digitalmars.com...
I was talking to Walter about Kenji's adaptTo. We both think it's a very
powerful enabler, but adaptTo is a bland name. After discussing a few
marketing strategies, I proposed duck. It's short, simple, and evokes
duck typing.
class C
{
int draw(){ return 10; }
}
interface Drawable
{
long draw();
}
...
auto c = new C;
auto d = duck!Drawable(c); // awes
Kenji, I'll be looking forward to your submission :o). Would be great to
allow structs to duck, too!
duck doesnt convey much meaning imo so.. why not adapt!
Ties in with the Adaptor design pattern.. which i'm guessing is what it
actualy does.
Re: duck!
I'd get used to Jimmy!, and thats a nice name too.
Jimmy Cao jcao...@gmail.com wrote in message
news:mailman.635.1287179560.858.digitalmar...@puremagic.com...
It doesn't matter if it sounds unintuitive to you right now,
eventually if you keep using it, the word will stick.
duck! is a nice name, so I'm fine with the idea.
On Fri, Oct 15, 2010 at 4:46 PM, JimBob j...@bob.com wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:i9ae2n$k9...@digitalmars.com...
I was talking to Walter about Kenji's adaptTo. We both think it's a very
powerful enabler, but adaptTo is a bland name. After discussing a few
marketing strategies, I proposed duck. It's short, simple, and evokes
duck typing.
class C
{
int draw(){ return 10; }
}
interface Drawable
{
long draw();
}
...
auto c = new C;
auto d = duck!Drawable(c); // awes
Kenji, I'll be looking forward to your submission :o). Would be great to
allow structs to duck, too!
duck doesnt convey much meaning imo so.. why not adapt!
Ties in with the Adaptor design pattern.. which i'm guessing is what it
actualy does.
Re: Redundancies often reveal bugs
bearophile bearophileh...@lycos.com wrote in message
news:i83cil$2o0...@digitalmars.com...
situations like x=x; reveal true bugs like:
class Foo {
int x, y;
this(int x_, int y_) {
this.x = x;
y = y;
}
}
I get hit much more often by somthing like this
class Foo {
int m_x, m_y;
this(int x, int y)
{
int m_x = x;
int m_y = y;
}
}
I dont know if it is, but IMO it really should be an error to declare local
variables that hide member variables.
Re: Redundancies often reveal bugs
Peter Alexander peter.alexander...@gmail.com wrote in message
news:i843rl$1gr...@digitalmars.com...
I dont know if it is, but IMO it really should be an error to declare
local
variables that hide member variables.
I disagree. I always do that in constructors:
int x, y;
this(int x, int y)
{
this.x = x;
this.y = y;
}
I think you would annoy a lot of people if it was forbidden.
I'm sure it would. But i think the benefit would outweigh the cost. I mean
the cost is coding style, personal preference, the benefit is fewer bugs.
And people would get used to it.
Re: The Wrong Stuff
Walter Bright newshou...@digitalmars.com wrote in message news:i7e7jp$1q7...@digitalmars.com... http://www.slate.com/blogs/blogs/thewrongstuff/archive/2010/06/28/risky-business-james-bagian-nasa-astronaut-turned-patient-safety-expert-on-being-wrong.aspx tl;dr: Telling people to be careful is not effective. Humans are not reliable that way. ... You need a solution that's not about making people perfect. This article doesn't say anything about software, but I think it is very applicable to programming and the design of programming languages. I often hear that a fault isn't a fault because we can educate programmers to avoid the problem. This article puts the kibosh on that. Errors that we can eliminate by changing the design of the language, we should so eliminate (unless their costs make the language unuseable, obviously). I read an article once where they were explaining how hospitals put a lot of effort designing procedures and protocols so that they minimizes human error. We have the phrase human error cause we humans are error prone. So particulary where peoples lives are at stake it's very worthwhile to do everything you can to minimize the possibility of it happening. One example was having the pharmacist set out each patients drugs and also have the nurse who gives them to the patient check each one. If humans have a 1/100 fail rate on such tasks, then the double check reduces it to 1/1.
Re: A summary of D's design principles
retard r...@tard.com.invalid wrote in message news:i73350$2m0...@digitalmars.com... Sat, 18 Sep 2010 11:45:51 -0700, Walter Bright wrote: retard wrote: It feels like we're having a conversation with a dinosaur. I apologize for all my numerous shortcomings! I'm sorry :-) But I still recommend writing couple of hundreds of lines of code in some ML. It's a great experience. If you wont go out of the house at least open the curtains for a bit.
Re: Overlooked Essentials for Optimizing Code
Walter Bright newshou...@digitalmars.com wrote in message news:i6e7tm$jj...@digitalmars.com... Nick Sabalausky wrote: 1. Using a profiler 2. Looking at the assembly code being executed Somehow I knew you were going to say that ;) What's interesting is how controversial this is. I've heard every reason in the book (and some very inventive ones) justifying not using a profiler or looking at the assembler. You also need to understand things that can cause problems with asm. For example the Borland compiler used to and probably still does often copy doubles by using 2 32 bit moves. This means any time they are loaded into the fpu soon after a copy you'll get a store to load forwarding stall, which can be around 30 cycles penalty. As float/doubles are passed via the stack, this meant quite a performance hit for code that used doubles over code that used single precision or extended. (Extended was coppied via the FPU so it want a problem).
Re: One more update on d-programming-language.org
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:i6bssf$25i...@digitalmars.com... http://d-programming-language.org From David Gileadi: the annoying Google Translate bar behavior on browsers with other languages has been fixed, the behavior when shrinking and growing the window size has been improved, the Reddit button is gone, and a few styles were changed. Could have sworn I sent this already, it just disappeared. I think the color scheme is better than the original. The blue/grey is much better than the sandy biege of the original. And there seems a better contrast on the sidebar for sure, and the main text is easier on the eye too. Thumbs up from me! note: Clicking on Library reference == The requested URL /phobos/phobos.html was not found on this server.
Re: Wrong and somewhat rude statement in your docs.
Elias Salomão Helou Neto el...@gmail.com wrote in message news:i3i41m$l1...@digitalmars.com... [Sorry for cross-posting, but I've just noticed that the other forum is deprecated.] Please modify your documentation, because the following part of it is even offensive. At least from my viewpoint. You must spend *all* of your waking life offended if that's how little it takes to set you off. ;-) By *all* I actually mean most. But I havnt yet decided whether my choice of wording was a crappy joke or a sarcastic reproach. But I added a smiley anyway.
Re: Plot2Kill 0.02
dsimcha dsim...@yahoo.com wrote in message
news:i2004b$2vv...@digitalmars.com...
== Quote from BLS (windev...@hotmail.de)'s article
On 19/07/2010 00:01, BLS wrote:
On 18/07/2010 22:36, dsimcha wrote:
heat maps
Sorry for my ignorance,
What are heat maps good for ?
Since I am more biz software guy, here my question.
Let's say I have this relation
A Project can have several Cost Centers.
A Cost Center can have several cost items.
I our sample . Project -P- has say, 10 cost centers.
Cost Center no 1 takes already 60 percent.
The other cost centers (2-10) just take between 10 (blue) and 20
(green)
percent.
-- So I want to color cost center no 1 related items in red.. . and the
max percentage item in cost center no 2 dark red.
CC No 1 = {5,20,20,15}
Is this what a heat map is made for ?
and sorry , best example I am able to give atm..
bjoern
My guess was okay, Heat maps are also made for this use case. so no need
to answer.
Since Tree maps are not that different from Heat maps, do you have any
plans to implement them too ?
I didn't have any plans to implement them, as I didn't know about them
until I
looked them up on Wikipedia just now. I'll consider implementing them,
but I'm
not sure if it will happen soon.
Next, Do you have any ideas about zooming ? (zooming a plotting region) ?
This can already be done programmatically (see Figure.xlim() and
Figure.ylim()),
but is not exposed yet via the default plot window GUI. This will be
exposed when
I decide how I want to expose it. The most obvious answer is dragging,
but the
question then becomes, how do you zoom back out?
What I do in one of my projects is : Press an hold the right mouse button to
select the point which stays fixed, then dragging up zooms in, dragging down
zooms out. If you set the zoom to work on an exponential scale it feels
better also. Ie, scale by pow(2, (mousey-starty)/20), or something like.
Re: data.d
Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vfvnf1bvtuz...@89-28-59-99.starnet.md... On Thu, 15 Jul 2010 11:03:57 +0300, JimBob j...@bob.com wrote: VirtualAlloc returns chunks that have 'dwAllocationGranularity' granularity, which is 64K on every Windows OS I've used. So allocating a page, 4K, will actualy get you 64K. So using VirtualAlloc as a replacement for malloc is very wasteful unless the allocations are larger that 64K. You might want to look at HeapCreate and it's siblings. (on windows anyway) dwAllocationGranularity only controls the granularity of the allocation address, but not of the allocation size. A simple program that calls VirtualAlloc 16384 times uses up 1 GB of the address space, but only 64 MB of actual memory. So, while it is a waste of address space, it's not a waste of system memory. Appologies, msdn says you're right. Which sucks cause I recently rewrote a bunch of code because of that misunderstanding. Thanks.
Re: D web site facelift
Walter Bright newshou...@digitalmars.com wrote in message news:i0m1qa$2va...@digitalmars.com... David Gileadi was kind enough to spend some time redesigning the look of the D web site. A preview of it is up on d-programming-language.org. This isn't about the content, just the look/style/feel. Comments welcome. Please don't put links to anything other than the front page yet, as the organization may change. It's a bit bland, lacking in contrast between the colors. Makes me think of the colors of desert camoflage. Look at these http://www.slate.com/id/2258128/ http://en.wikipedia.org/wiki/Andean_Condor http://docs.python.org/py3k/ Then look at http://www.d-programming-language.org/ Maybe you can see what I mean. Anything that has a lots of text needs more contrast between text and background. And generally you find most profesional sites have 2 or 3 *different* colors, and then maybe a few more shades of those. Not just 3 shades of the same color.
Re: Floating point rounding modes: we should restrict them slightly
#ponce alil...@gmail.com wrote in message news:h8adr2$23p...@digitalmars.com... Why not imposing a rounding mode (ex : toward minus infinity) ? And then disallowing to change it in assembly. I mean, you can still do : round(x) as floor(x + 0.5L) ceil(x) as floor(x + 1.0L) Iit would cost some precision with large floating-point number, but not much since rounding such large numbers has few meaning. It would clear up the rounding-mode mess a bit. There's more to rounding modes than just converting / rounding to integer. Rounding affects all arithmetic operations, and whether an expresion evaluates to 0.97999 or .97998 can be important in some cases.
Re: Exponential operator
bearophile bearophileh...@lycos.com wrote in message news:h5h3uf$23s...@digitalmars.com... Lars T. Kyllingstad: He also proposed that the overload be called opPower. I want to add to two small things to that post of mine: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=95123 The name opPow() may be good enough instead of opPower(). And A^^3 may be faster than A*A*A when A isn't a simple number, so always replacing the power with mults may be bad. It wont be on x86. Multiplication has a latency of around 4 cycles whether int or float, so x*x*x will clock around 12 cycles. The main instruction needed for pow, F2XM1, costs anywhere from 50 cycles to 120, depending on the cpu. And then you need to do a bunch of other stuff to make F2XM1 handle different bases.
Re: Exponential operator
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:4a7c5313.10...@erdani.org... Jimbob wrote: bearophile bearophileh...@lycos.com wrote in message news:h5h3uf$23s...@digitalmars.com... Lars T. Kyllingstad: He also proposed that the overload be called opPower. I want to add to two small things to that post of mine: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=95123 The name opPow() may be good enough instead of opPower(). And A^^3 may be faster than A*A*A when A isn't a simple number, so always replacing the power with mults may be bad. It wont be on x86. Multiplication has a latency of around 4 cycles whether int or float, so x*x*x will clock around 12 cycles. Yeah, but what's the throughput? With multiple ALUs you can get several multiplications fast, even though getting the first one incurs a latency. In this case you incur the latency of every mul because each one needs the result of the previous mul before it can start. Thats the main reason trancendentals take so long to compute, cause they have large dependancy chains which make it difficult, if not imposible for any of it to be done in parallel.
Re: Exponential operator
bearophile bearophileh...@lycos.com wrote in message news:h5hvhh$if...@digitalmars.com... Jimbob Wrote: bearophile: And A^^3 may be faster than A*A*A when A isn't a simple number, so always replacing the power with mults may be bad. It wont be on x86. Multiplication has a latency of around 4 cycles whether int or float, so x*x*x will clock around 12 cycles. The main instruction needed for pow, F2XM1, costs anywhere from 50 cycles to 120, depending on the cpu. And then you need to do a bunch of other stuff to make F2XM1 handle different bases. I don't understand what you mean. But when A isn't a simple number means for example when A is a matrix. Oops, my brain didnt parse what you meant by simple number.
Re: Properties: a.b.c = 3
Walter Bright newshou...@digitalmars.com wrote in message
news:h4ocet$27...@digitalmars.com...
The issue is what if b is a property, returns a temporary object, and that
temp's .c field is uselessly set to 3?
It's a classic problem with properties that are implemented as functions.
I don't see how C#'s special property syntax adds any value for dealing
with this.
One thought I had was to simply disallow the '.' to appear after a
function style property.
Disallow it by default. IE.
a.b.c.d = 3;
If any of those return an rvalue / temporary then it should be an error to
assign to it.
However we should not disallow...
int i = a.b.c.d.e.f;
But we should also find a way to let the programmer tell the compiler if it
is ok for it to rewrite...
a.b.c = 3;
as
B tmp = a.b;
tmp.c = 3;
a.b = tmp;
perhaps an extra operator opSubAssign() Which tells the compiler it's ok
to rewrite the the assignment using temporrarys and reassignment.
class A
{
B _b;
void b.opAssign(ref B bbb) { _b = bbb; }
void b.opSubAssign(ref B bbb) { opAssign(bbb); }
}
Then the programmer could also write an specialized subassignment.
Re: new DIP5: Properties 2
Kagamin s...@here.lot wrote in message
news:h4jq11$1jv...@digitalmars.com...
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP5
As namespaces were proposed, a variant of them is in DIP5 now.
Why not just..
class Foo
{
private:
int mx;
public:
int x.opGet() { return mx; }
void x.opSet(int i) { mx = i; }
void x.opInc() { mx++; }
}
or instead...
class Foo
{
private:
int mx;
public:
int x:opGet() { return mx; }
void x:opSet(int i) { mx = i; }
void x:opInc() { mx++; }
}
So that
foo.x++;
Would be compiled as
foo.x.opInc();
In the same way
foo++;
Would is compiled as
foo.opInc();
