My only assumption is that -version=runtime doesn't utilize ctfe and
the other does. The rest is simple timing on both linux and windows
and ctfe is way slower...
2012/12/18 bearophile :
> maarten van damme:
>
>> How can this be?
>
>
> Maybe there are some mistakes in your assumptions.
>
> Bye,
>
maarten van damme:
How can this be?
Maybe there are some mistakes in your assumptions.
Bye,
bearophilwe
On Monday, 17 December 2012 at 22:47:33 UTC, bearophile wrote:
maarten van damme:
How do I make dmd output asm?
You can't, unfortunately. They closed this enhancement request
of mine because they say DMD is not designed for this.
On Linux there are several disassemblers, I use objdump. On
On 12/17/2012 02:47 PM, bearophile wrote:
maarten van damme:
How do I make dmd output asm?
You can't, unfortunately. They closed this enhancement request of mine
because they say DMD is not designed for this.
On Linux there are several disassemblers, I use objdump. On Windows
there are other
maarten van damme:
How do I make dmd output asm?
You can't, unfortunately. They closed this enhancement request of
mine because they say DMD is not designed for this.
On Linux there are several disassemblers, I use objdump. On
Windows there are other ones.
Bye,
bearophile
How do I make dmd output asm?
I wrote a simple test and for a simple int[] array it was 2,5 times slower.
2012/12/17 bearophile :
> maarten van damme:
>
>
>> it's odd that the resulting arraylist is slower to access at runtime
>> then the arraylist generated at runtime... Is there a reason for th
maarten van damme:
it's odd that the resulting arraylist is slower to access at
runtime
then the arraylist generated at runtime... Is there a reason
for this?
In such cases, beside thinking some time about the topic, one
solution is to take a look at the asm.
Maybe it's the same problem as
Thanks, I'm really happy it works now.
it's odd that the resulting arraylist is slower to access at runtime
then the arraylist generated at runtime... Is there a reason for this?
Should I open bugreports for your testcases?
2012/12/17 bearophile :
>> I think it's a problem of nested delegates at
I think it's a problem of nested delegates at CT. But if this
is the problem, dmd used to give a more clear error message.
Two minimized programs that show the problems:
-
import std.algorithm: filter;
import std.array: array;
auto foo(in int x) {
return [1, 2].filter!(i => x)(
maarten van damme:
Here is a trimmed down version : http://dpaste.dzfl.pl/11170641
thanks for the quick reply.
It seems to work if you move ".array()" from
generateBitsetCache() to bitsetToRange(). I think it's a problem
of nested delegates at CT. But if this is the problem, dmd used
to gi
maarten van damme:
I always get "variable x cannot be read at compile time" in
this method :
auto bitsetToRange(in SudokuCell x) {
return boardSide.iota().filter!(i => (x >> i) &
1)().map!(x=>x+1)();
}
with SudokuCell beeing declared as:
alias ushort SudokuCell;
Why don't you show us
On Monday, 17 December 2012 at 09:42:50 UTC, maarten van damme
wrote:
I finally got around trying to finish my sudoksolver and I'm
pretty
happy with the result, except one little piece that screams for
ctfe
but I never seem to get it working.
I always get "variable x cannot be read at compile t
I finally got around trying to finish my sudoksolver and I'm pretty
happy with the result, except one little piece that screams for ctfe
but I never seem to get it working.
I always get "variable x cannot be read at compile time" in this method :
auto bitsetToRange(in SudokuCell x) {
return bo
13 matches
Mail list logo
