dsimcha wrote:
I consider the function-delegate thing a reasonably solved problem, starting in
the next release of Phobos. See:
http://dsource.org/projects/phobos/changeset/1428
Nice.
Btw, I'm guessing that pragma(msg) in line 562 should be commented out
before release? :)
On Wed, 03 Mar 2010 01:00:46 -0500, Steve Teale
wrote:
* Binding a delegate to a function pointer will always need a (dynamic)
thunk, because the function will have been invoked without any context
pointer and it's the thunk's responsibility to assign the correct
context pointer.
At present
> * Binding a delegate to a function pointer will always need a (dynamic)
> thunk, because the function will have been invoked without any context
> pointer and it's the thunk's responsibility to assign the correct
> context pointer.
At present, D's way of handling delegates requires patching GC
>
> I will check into a range re-education camp until my mind is
> enlightened.
>
> Paul
That's exactly how I felt when I discovered this gem of clarity and
Andrei enlightened me.
Steve
On Tue, 02 Mar 2010 23:01:01 -0500, Rainer Deyke
wrote:
On 3/2/2010 14:28, Don wrote:
retard wrote:
Why not dynamic code path selection:
if (cpu_capabilities && SSE4_2)
run_fast_method();
else if (cpu_capabilities && SSE2)
run_medium_fast_method();
else
run_slow_method();
One could
On 3/2/2010 14:28, Don wrote:
> retard wrote:
>> Why not dynamic code path selection:
>>
>> if (cpu_capabilities && SSE4_2)
>> run_fast_method();
>> else if (cpu_capabilities && SSE2)
>> run_medium_fast_method();
>> else
>> run_slow_method();
>>
>> One could also use higher level design patte
I consider the function-delegate thing a reasonably solved problem, starting in
the next release of Phobos. See:
http://dsource.org/projects/phobos/changeset/1428
dsimcha:
> Is SSE(2) inherently faster then (at least in real-world implementations) than
> x87, even when you don't vectorize?<
sqrt for example is fast, and there are other high level instructions (for
video decoding cryptography, etc).
But you have to think how much time has passed from the de
That or just use something like this: http://gist.github.com/263824
On Tue, 02 Mar 2010 21:02:51 -0500, Lionello Lunesu
wrote:
The following has been discussed for years, and the biggest problem
(years ago) was that it was too late to change the D (1) ABI.
Is the D2 ABI compatible with D1? Should it be? If not, please consider
the following change:
alias void
The following has been discussed for years, and the biggest problem
(years ago) was that it was too late to change the D (1) ABI.
Is the D2 ABI compatible with D1? Should it be? If not, please consider
the following change:
alias void delegate() action_d;
void Callback() { } // global
"Don" wrote in message
news:hmk01v$1u3...@digitalmars.com...
> retard wrote:
>> Tue, 02 Mar 2010 14:17:12 -0500, Nick Sabalausky wrote:
>>
>>> "retard" wrote in message
>>> news:hmjmjd$15u...@digitalmars.com...
Tue, 02 Mar 2010 15:49:02 +, dsimcha wrote:
> Given that Walter has
== Quote from Don (nos...@nospam.com)'s article
> Of course, in the occasions when SSE lets you do 4 operations at once,
> you get nearly a 4X speedup...
Is SSE(2) inherently faster then (at least in real-world implementations) than
x87, even when you don't vectorize? Would I be able to expect an
retard wrote:
Tue, 02 Mar 2010 14:17:12 -0500, Nick Sabalausky wrote:
"retard" wrote in message
news:hmjmjd$15u...@digitalmars.com...
Tue, 02 Mar 2010 15:49:02 +, dsimcha wrote:
Given that Walter has indicated that 64-bit support is on the agenda
for after D2 is finished and x87 is depr
bearophile wrote:
Don:
To get the full benefit from SSE we need to use SSE registers for
parameter passing, but I think that'll only be possible with the 64 bit API.
Can you explain me this a bit better? Why can't D use SSE registers in 32 bit
code too?
Bye,
bearophile
It can, but not in t
bearophile wrote:
>
> This can be done just keeping asserts in the precondition, and putting the
> exceptions in the body (if you are a really tidy person you can even
> disable the exceptions in not release built). But in practice I think the
> "good enough" thing to do is to be sure essential pr
retard:
>The full potential hasn't been realized yet.<
I'm sure there's space for improvements. But I have yet to see benchmarks that
show improvements compared to those shown in the thesis.
>Also the thesis doesn't mention Don's genetic algorithm stuff<
Genetic algorithms can be used with GCC
Kagamin:
> Never deemed -release flag as a useful thing, may be I just don't put in
> useless asserts?
-release disables array bounds tests too. This can produce D code 2-3 times
faster if you process array a lot, because DMD is not (as recent versions of
Java HotSpot) able to infer many situa
Tue, 02 Mar 2010 15:33:58 -0500, bearophile wrote:
> retard:
>> Can you cite any sources? I'd like to know the cases where GCC is
>> faster than the don's new approach.
>
> The thesis, page 52 (page 61 of the PDF):
> http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf
Did you notice that he
retard:
> Can you cite any sources? I'd like to know the cases where GCC is faster
> than the don's new approach.
The thesis, page 52 (page 61 of the PDF):
http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf
Bye,
bearophile
bearophile Wrote:
> I think most D programmers today want to remove runtime checks for unproven
> assertions, that's the point of the -release compile flag.
>
Never deemed -release flag as a useful thing, may be I just don't put in
useless asserts?
And I don't think that detailed exceptions do a
Tue, 02 Mar 2010 15:13:10 -0500, Nick Sabalausky wrote:
> "dsimcha" wrote in message
> news:hmjpkt$1i2...@digitalmars.com...
>> == Quote from retard (r...@tard.com.invalid)'s article
>>> Tue, 02 Mar 2010 14:17:12 -0500, Nick Sabalausky wrote:
>>> > "retard" wrote in message
>>> > news:hmjmjd$15u
"dsimcha" wrote in message
news:hmjpkt$1i2...@digitalmars.com...
> == Quote from retard (r...@tard.com.invalid)'s article
>> Tue, 02 Mar 2010 14:17:12 -0500, Nick Sabalausky wrote:
>> > "retard" wrote in message
>> > news:hmjmjd$15u...@digitalmars.com...
>> >>
>> >> SSE(2) ? Don't people already
Tue, 02 Mar 2010 11:57:13 -0800, Walter Bright wrote:
> bearophile wrote:
>> Walter Bright:
>>> 5. I've discovered over the years that programmers write in particular
>>> "islands" of the language. No matter how large a code base they
>>> produce, they never stray outside that island, so once the
Don:
> To get the full benefit from SSE we need to use SSE registers for
> parameter passing, but I think that'll only be possible with the 64 bit API.
Can you explain me this a bit better? Why can't D use SSE registers in 32 bit
code too?
Bye,
bearophile
Tue, 02 Mar 2010 14:55:05 -0500, bearophile wrote:
> retard:
>> - a new llvm based backend which is a lot faster
>
> I guess most people on Reddit has not read the original thesis. The LLVM
> Haskell back-end: - Needs less code to be used by the front-end, this is
> quite positive for them. - LL
bearophile wrote:
Walter Bright:
5. I've discovered over the years that programmers write in
particular "islands" of the language. No matter how large a code
base they produce, they never stray outside that island, so once
the bugs they initially encountered are fixed, they never run into
compil
retard:
> - a new llvm based backend which is a lot faster
I guess most people on Reddit has not read the original thesis. The LLVM
Haskell back-end:
- Needs less code to be used by the front-end, this is quite positive for them.
- LLVM compiles better certain heavy numerical kernels. So if you
Tue, 02 Mar 2010 19:46:20 +, retard wrote:
> At least popular video decoders like mplayer seem to have dynamic cpu
> detection. No idea, how it exactly affects the instructions used in the
> code. Well, there are all kinds of x86 clones out there. I don't
> remember what instructions they all
Tue, 02 Mar 2010 19:41:17 +, dsimcha wrote:
> == Quote from retard (r...@tard.com.invalid)'s article
>> Tue, 02 Mar 2010 14:17:12 -0500, Nick Sabalausky wrote:
>> > "retard" wrote in message
>> > news:hmjmjd$15u...@digitalmars.com...
>> >> Tue, 02 Mar 2010 15:49:02 +, dsimcha wrote:
>> >>
== Quote from retard (r...@tard.com.invalid)'s article
> Tue, 02 Mar 2010 14:17:12 -0500, Nick Sabalausky wrote:
> > "retard" wrote in message
> > news:hmjmjd$15u...@digitalmars.com...
> >> Tue, 02 Mar 2010 15:49:02 +, dsimcha wrote:
> >>
> >>> Given that Walter has indicated that 64-bit suppo
Tue, 02 Mar 2010 14:17:12 -0500, Nick Sabalausky wrote:
> "retard" wrote in message
> news:hmjmjd$15u...@digitalmars.com...
>> Tue, 02 Mar 2010 15:49:02 +, dsimcha wrote:
>>
>>> Given that Walter has indicated that 64-bit support is on the agenda
>>> for after D2 is finished and x87 is deprec
"retard" wrote in message
news:hmjmjd$15u...@digitalmars.com...
> Tue, 02 Mar 2010 15:49:02 +, dsimcha wrote:
>
>> Given that Walter has indicated that 64-bit support is on the agenda for
>> after D2 is finished and x87 is deprecated in 64-bit mode, will we also
>> see SSE(2) support in DMD i
Mon, 01 Mar 2010 16:10:33 -0500, Jeff Nowakowski wrote:
> Andrei Alexandrescu wrote:
>> I'm telling you that pre-monads there was an I/O paradigm that
>> everybody FP swore by.
>
> I looked this up out of curiosity. The Haskell 1.2 report, circa 1992,
> talks about "streams of messages" and also
dsimcha wrote:
Given that Walter has indicated that 64-bit support is on the agenda for after
D2 is finished and x87 is deprecated in 64-bit mode, will we also see SSE(2)
support in DMD in the relatively near future? If so, will it be exposed as a
compiler option even when compiling in 32-bit mo
Tue, 02 Mar 2010 15:49:02 +, dsimcha wrote:
> Given that Walter has indicated that 64-bit support is on the agenda for
> after D2 is finished and x87 is deprecated in 64-bit mode, will we also
> see SSE(2) support in DMD in the relatively near future? If so, will it
> be exposed as a compiler
Lars T. Kyllingstad Wrote:
> Paul D. Anderson wrote:
> > I've entered this as a Phobos bug, but wanted to be sure I was
> > understanding this properly (i.e., this is a bug, right?):
> >
> > From the description of the put primitive in std.range:
> >
> > "r.put(e) puts e in the range (in a rang
dsimcha:
>In D2, isn't that what enforce() is for?<
You are probably right :-)
Have Andrei design part of the standard library is not enough, I also have to
understand why the idioms it encourages are good :-) Now I have understood what
enforce is useful for (as a shortcut for a test+throw), bu
bearophile wrote:
> What do you think? Do you agree that's better to use exceptions like this
> to test arguments in public methods (instead of using asserts in
> preconditions)?
Short answer: No!
Longer answer:
It depends. With exceptions, your methods and constructors basically double
as a te
dsimcha wrote:
== Quote from Fawzi Mohamed (fa...@gmx.ch)'s article
I already thought that having a aassert (always assert) would
be nice...
In D2, isn't that what enforce() is for?
It is indeed.
I've found enforce() to be extremely practical. I use it every time I
would otherwise write
Theoretically exceptions are situations you expect can happen, even though
the code is bug free, while assertions always indicate a bug.
I think the main implication of this is that assertions should behave
differently. They should halt the program at once so the developer's
attention is force
== Quote from Fawzi Mohamed (fa...@gmx.ch)'s article
> I already thought that having a aassert (always assert) would
> be nice...
In D2, isn't that what enforce() is for?
Fawzi Mohamed wrote:
On 2-mar-10, at 15:50, Norbert Nemec wrote:
bearophile wrote:
But generally public functions must test arguments in release mode
too, so I (and lot of other people) don't like to use asserts in this
situation. It's better to use an always present test followed by a
thr
Given that Walter has indicated that 64-bit support is on the agenda for after
D2 is finished and x87 is deprecated in 64-bit mode, will we also see SSE(2)
support in DMD in the relatively near future? If so, will it be exposed as a
compiler option even when compiling in 32-bit mode?
I've realize
On 2-mar-10, at 15:50, Norbert Nemec wrote:
bearophile wrote:
But generally public functions must test arguments in release mode
too, so I (and lot of other people) don't like to use asserts in
this situation. It's better to use an always present test followed
by a throw (so such test is
bearophile wrote:
But generally public functions must test arguments in release mode too, so I
(and lot of other people) don't like to use asserts in this situation. It's
better to use an always present test followed by a throw (so such test is not
in the precondition).
For this statement,
On Mon, Mar 1, 2010 at 22:51, Lars T. Kyllingstad
wrote:
> Paul D. Anderson wrote:
>
from std.range
> "r.put(e) puts e in the range (in a range-dependent manner) and advances
>> to the popFront position in the range. Successive calls to r.put add
>> elements to the range. put may throw to signa
Walter Bright:
> 5. I've discovered over the years that programmers write in particular
> "islands" of the language. No matter how large a code base they produce,
> they never stray outside that island, so once the bugs they initially
> encountered are fixed, they never run into compiler bugs an
In Java there are few uncommon situations where it's useful to put side effects
inside asserts.
This Java code manipulates an array, and then wants to assert something about
this computation. To perform such tests it needs the old array, that has to be
copied. But in release mode the programmer
This is currently present in this Wikipedia page:
http://en.wikipedia.org/wiki/Class_invariant#D
It shows a normal way to use contract programming in D:
class Date {
private int day, hour;
invariant() {
assert(1 <= day && day <= 31);
assert(0 <= hour && hour < 24);
}
On 2010-03-02 09:25:05 +0100, Walter Bright said:
Fawzi Mohamed wrote:
that s good, but maybe for a release one should also try to compile
some of the largish projects that are done in D (even al older frozen
version) to see if in larger codebases something comes up...
At least for D 1.0 on a
Fawzi Mohamed wrote:
that s good, but maybe for a release one should also try to compile some
of the largish projects that are done in D (even al older frozen
version) to see if in larger codebases something comes up...
At least for D 1.0 on a fixed system the idea "if id did compile it
should
52 matches
Mail list logo
