Re: Help optimizing code?

2018-01-01 Thread Muld via Digitalmars-d-learn

On Monday, 1 January 2018 at 16:47:40 UTC, Adam D. Ruppe wrote:

On Monday, 1 January 2018 at 16:13:37 UTC, Muld wrote:
If you use .ptr then you get zero detection, even in debug 
builds.


It is limited to the one expression where you wrote it, instead 
of on the ENTIRE program like the build switches do.


It is a lot easier to check correctness in an individual 
expression than it is to check the entire program, including 
stuff you didn't even realize might have been a problem.


With the .ptr pattern, it is correct by default and you 
individually change ones you (should) look carefully at. With 
-boundscheck, it is wrong by default and most people don't even 
look at it - people suggest it to newbies as an optimization 
without mentioning how nasty it is.


It won't be just one line though. When you pretty much have to 
use it EVERYWHERE to get the optimization you want. It makes more 
sense to just turn off the check for the entire program and use 
your own asserts() where they are actually needed. That way you 
still get the checks in debug builds and have asserts where they 
are actually necessary.


I'd rather there be a potential bug than the program running 
to slow to be usable


That's a ridiculous exaggeration. In this program, I saw a < 1% 
time difference using those flags. -O -inline make a 50x bigger 
difference!


Read the sentence right before this.. Jesus. People only read 
what they want.



or have zero debugging for indices in debug builds.


You shouldn't be using .ptr until after you've carefully 
checked and debugged the line of code where you are writing it. 
That's the beauty of the pattern: it only affects one line of 
code, so you can test it before you use it without affecting 
the rest of the program.


It won't just be one line, and that's not beautiful. What happens 
when code gets refactored? You are constantly going to be 
flip-flopping the source code rather than a compiler flag or 
using multiple build configurations? How long are you even going 
to test for? The error that might happen for the code is probably 
difficult to detect, if it wasn't then having bounds checking at 
all wouldn't be necessary. Just test your code, that's the beauty 
of testing!




Re: Help optimizing code?

2018-01-01 Thread Muld via Digitalmars-d-learn

On Monday, 1 January 2018 at 15:54:33 UTC, Adam D. Ruppe wrote:

On Monday, 1 January 2018 at 15:29:28 UTC, user1234 wrote:

dmd mandelbrot.d -O -release -inline -boundscheck=off


-O and -inline are OK, but -release and -boundscheck are 
harmful and shouldn't be used. Yeah, you can squeeze a bit of 
speed out of them, but there's another way to do it - `.ptr` on 
the individual accesses or versioning out unwanted `assert` 
statements - and those avoid major bug and security baggage 
that -release and -boundscheck=off bring.


If you use .ptr then you get zero detection, even in debug builds.

In this program, I didn't see a major improvement with the 
boundscheck skipping... and in this program, it seems to be 
written without the bugs, but still, I am against that switch 
on principle. It is so so so easy to break things with them.


In this program, it's relatively small and doesn't look like it 
does its calculations in realtime. I'd rather there be a 
potential bug than the program running to slow to be usable, or 
have zero debugging for indices in debug builds.







Re: Slices and Dynamic Arrays

2017-12-29 Thread Muld via Digitalmars-d-learn

On Friday, 29 December 2017 at 22:32:01 UTC, Tony wrote:

In DLang Tour:Arrays
https://tour.dlang.org/tour/en/basics/arrays

there is:
---
int size = 8; // run-time variable
int[] arr = new int[size];

The type of arr is int[], which is a slice.
---

In "D Slices"
https://dlang.org/d-array-article.html

there is:
---
int[] a; // a is a slice


Based on those two web pages it appears that the name for a 
dynamic array  in D is "slice". That is, anytime 
you have a dynamic array (even a null reference version) it is 
called a slice. Is that correct?


Not really, cause you can take a "slice" of a linked list (though 
inefficiently), but a linked list isn't an array. You can also 
take a "slice" of a stack allocated array.




Re: Compiler gets confused with ambiguity when `int` matches both `real` and `float`.

2017-12-23 Thread Muld via Digitalmars-d-learn

On Saturday, 23 December 2017 at 07:25:34 UTC, IM wrote:

The following expression:

import std.math : sqrt;
sqrt(400);

produces the following compiler error:

std.math.sqrt called with argument types (int) matches both:
/usr/include/dmd/phobos/std/math.d(1592,7): 
std.math.sqrt(float x)

and:
/usr/include/dmd/phobos/std/math.d(1598,6): 
std.math.sqrt(real x)


Shouldn't it just pick one according to some defined rules?


C++ complains the same between float and double. Just put 400.0f 
or whatever precision you want to use. I think it's better that 
it doesn't just pick one.