On Sunday, 24 March 2024 at 22:16:06 UTC, Kdevel wrote:
The term containing the `pow` invocation computes the
alternating sequence -1, 1, -1, ..., which can be replaced by
e.g.
```d
immutable int [2] sign = [-1, 1];
n += sign [i & 1] / (i * 2.0 - 1.0);
```
This saves the expensive call
On Sunday, 24 March 2024 at 22:16:06 UTC, rkompass wrote:
Are there some simple switches / settings to get a smaller
binary?
1) If possible you can use "betterC" - to disable runtime
2) otherwise
```bash
--release --O3 --flto=full -fvisibility=hidden
The term containing the `pow` invocation computes the
alternating sequence -1, 1, -1, ..., which can be replaced by
e.g.
```
immutable int [2] sign = [-1, 1];
n += sign [i & 1] / (i * 2.0 - 1.0);
```
This saves the expensive call to the pow function.
I used the loop:
```d
for
On Saturday, 23 March 2024 at 04:32:29 UTC, harakim wrote:
* You should probably not do this, but it might give you some
ideas for later. What I would do is make a separate thread for
managing the UI state and push events to that thread through
the mailbox. I have done this once (on my third
On Sunday, 24 March 2024 at 19:31:19 UTC, Csaba wrote:
I know that benchmarks are always controversial and depend on a
lot of factors. So far, I read that D performs very well in
benchmarks, as well, if not better, as C.
I wrote a little program that approximates PI using the Leibniz
On Sunday, 24 March 2024 at 19:31:19 UTC, Csaba wrote:
As you can see the function that does the job is exactly the
same in C and D.
Not really..
The speed of Leibniz algo is mostly the same. You can check the
code in this benchmark for example:
On Sunday, 24 March 2024 at 19:31:19 UTC, Csaba wrote:
...
Here are the results:
C: 0.04s
Python: 0.33s
D: 0.73s
...
I think a few things can be going on, but one way to go is trying
using optimization flags like "-O2", and run again.
But anyway, looking through Assembly generated:
C:
I know that benchmarks are always controversial and depend on a
lot of factors. So far, I read that D performs very well in
benchmarks, as well, if not better, as C.
I wrote a little program that approximates PI using the Leibniz
formula. I implemented the same thing in C, D and Python, all
On Saturday, 23 March 2024 at 20:49:14 UTC, Nick Treleaven wrote:
On Saturday, 23 March 2024 at 19:30:29 UTC, Menjanahary R. R.
wrote:
for (T candidate = T(5); candidate * candidate <= n;
candidate += T(6)) {
When T is `const int`, the above code declares and initializes
a constant
On Saturday, 23 March 2024 at 20:38:40 UTC, Jonathan M Davis
wrote:
On Saturday, March 23, 2024 1:30:29 PM MDT Menjanahary R. R.
via Digitalmars- d-learn wrote:
[...]
Well, when nextPrime is instantiated, the type of T is inferred
from the function argument. So, if num is int, then T is int,
On Saturday, 23 March 2024 at 21:59:57 UTC, Nick Treleaven wrote:
On Saturday, 23 March 2024 at 21:53:43 UTC, Jonathan M Davis
wrote:
Yes, it's a bug. It's a clear violation of the type system if
a non-mutable variable is ever given a value more than once.
It should be initialized, and then it
On Sunday, March 24, 2024 1:41:41 AM MDT Dom DiSc via Digitalmars-d-learn
wrote:
> I'm creating a library that is completely pure, but it doesn't
> compile with pure: at the top because of one impure unittest
> (which uses random to test some things only probabilistic)!
>
> So do I really need
12 matches
Mail list logo
