On Saturday, 28 September 2024 at 08:35:39 UTC, Johan wrote:
On Saturday, 28 September 2024 at 07:54:40 UTC, Dakota wrote:
```c
struct __attribute__((packed)) type1 {
uint32_tu32;
uint8_t u8;
uint16_tu16a;
uint16_tu16b;
uint8_t u8a;
On Saturday, 28 September 2024 at 07:54:40 UTC, Dakota wrote:
```c
struct __attribute__((packed)) type1 {
uint32_tu32;
uint8_t u8;
uint16_tu16a;
uint16_tu16b;
uint8_t u8a;
uint8_t arr[14];
};
```
the struct size in C is 24:
On Friday, 20 September 2024 at 16:21:10 UTC, Nick Treleaven
wrote:
On Friday, 20 September 2024 at 09:38:54 UTC, Dakota wrote:
Thanks to Dennis for the workaround.
Thanks your all for the tips, void solution fix me problem.
On Friday, 20 September 2024 at 09:38:54 UTC, Dakota wrote:
I need my struct defined as `isZeroInit`, so can I can import
them as `di` file. (this also reduce build size)
But I find this problem with float inside union:
```d
struct test_t {
union {
int i32;
float f32;
On Friday, 20 September 2024 at 09:38:54 UTC, Dakota wrote:
I need my struct defined as `isZeroInit`, so can I can import
them as `di` file. (this also reduce build size)
But I find this problem with float inside union:
```d
struct test_t {
union {
int i32;
float f32;
On Friday, 20 September 2024 at 09:38:54 UTC, Dakota wrote:
I consider this is compiler bug (it may take years to get fixed)
I've sent issues for compiler bugs and had them fixed within the
next release—about month, not years.
Also yes, this seems to be a compiler bug; unless there's some
s
I need my struct defined as `isZeroInit`, so can I can import
them as `di` file. (this also reduce build size)
But I find this problem with float inside union:
```d
struct test_t {
union {
int i32;
float f32;
}
}
static assert(__traits(isZeroInit, test_t) );
```
``
On Friday, 23 August 2024 at 05:50:43 UTC, Dakota wrote:
any suggestions how to fix this?
```sh
/ldc/bin/../import/core/stdc/stdio.d(31): Error: module ```
I dont use the std with wasm, everything imports everything else
and there are just broken symbols deep in "core" that wont be
fixed
On Thursday, 22 August 2024 at 21:19:57 UTC, monkyyy wrote:
On Thursday, 22 August 2024 at 07:28:00 UTC, Dakota wrote:
Is there a way to link ldc objects with Emscripten to build
wasm binary ?
yes; you'll have to untangle my build system
https://github.com/crazymonkyyy/raylib-2024
It will al
On Thursday, 22 August 2024 at 07:28:00 UTC, Dakota wrote:
Is there a way to link ldc objects with Emscripten to build
wasm binary ?
yes; you'll have to untangle my build system
https://github.com/crazymonkyyy/raylib-2024
It will always suck tho
On Thursday, 22 August 2024 at 07:28:00 UTC, Dakota wrote:
Is there a way to link ldc objects with Emscripten to build
wasm binary ?
Some years a go, i was able to build and run my hobby game using
EMScripen. Things must be changed now. I drop the link here. I
cannot help further since i
On Monday, 15 July 2024 at 11:16:23 UTC, Nick Treleaven wrote:
I put `type_s` in a file anonstruct.c, then:
```d
import anonstruct;
pragma(msg, isStatic!(type_s.c));
```
That outputs `false`, because the symbol is not a compile-time
value. Is that what you meant?
No, I am here deal with a lo
On Monday, 15 July 2024 at 06:44:12 UTC, Dakota wrote:
```d
struct type_s
{
union {
struct
{
int a;
int b;
} c;
};
};
```
`type c` will return false with `enum isStatic(alias V) =
__traits(compiles, { enum v = V; });`
I put `type_s` in
On Monday, 1 July 2024 at 11:15:46 UTC, Nick Treleaven wrote:
```
There is a case check will give wrong resutls:
```d
struct type_s
{
union {
struct
{
int a;
int b;
} c;
};
};
```
`type c` will return false with `enum isStatic(alias V
On Wednesday, 3 July 2024 at 21:47:32 UTC, Tim wrote:
If you only want to see the layout, you can use the following
command to dump it:
```
clang test.c -Xclang -fdump-record-layouts -c
```
File test.c could contain the following:
```
struct S
{
int a : 3;
int b : 29;
};
struct S dummy;
On Tuesday, 2 July 2024 at 05:34:19 UTC, Dakota wrote:
I want to get `bitoffsetof` and `bitwidth` in clang, to verify
the d memory layout.
I try this but not work:
```c
#define offsetof_bit(type, member) ((offsetof(type, member) *
8) + __builtin_ctz(((type *)0)->member))
```
get this error
On Monday, 1 July 2024 at 11:15:46 UTC, Nick Treleaven wrote:
On Monday, 1 July 2024 at 07:32:30 UTC, Dakota wrote:
this code give error:
```d
static if( !__traits(compiles, mixin("enum v = V;")) ) {
enum v = V;
}
```
__traits(compiles, ...) can't check if a declaration is valid
directl
On Monday, 1 July 2024 at 07:32:30 UTC, Dakota wrote:
this code give error:
```d
static if( !__traits(compiles, mixin("enum v = V;")) ) {
enum v = V;
}
```
__traits(compiles, ...) can't check if a declaration is valid
directly. You have to wrap it in a function literal expression:
```d
this code give error:
```d
static if( !__traits(compiles, mixin("enum v = V;")) ) {
enum v = V;
}
```
```sh
Error: static variable `NotWorkVar` cannot be read at compile
time
```
V is alias get from `typeof(__traits(getMember, M, symbol)`, M
is `module` from importC.
the importC so
On Wednesday, 29 May 2024 at 09:01:13 UTC, evilrat wrote:
On Wednesday, 29 May 2024 at 07:47:01 UTC, Dakota wrote:
[...]
(here is the signature of callback)
https://github.com/microsoft/garnet/blob/ade2991f3737b9b5e3151d0dd0b614adfd4bcecd/libs/storage/Tsavorite/cc/src/device/async.h#L25
[...
garnet source code to
support pass a C function callback)
I am newbie to C++ and D, any help will be appreciate
(here is the signature of callback)
https://github.com/microsoft/garnet/blob/ade2991f3737b9b5e3151d0dd0b614adfd4bcecd/libs/storage/Tsavorite/cc/src/device/async.h#L25
```cpp
typede
k)
I am newbie to C++ and D, any help will be appreciate
I found a way to make a solution for 64 bit Windows mechanically
with many MSVC intrinsics, using only mingw64.
Here's an [MSYS2](https://www.msys2.org/) bash script.
```bash
gcc -E -P intrin.c -o vcintrinsics.c
sed -i 's/extern __inline__
__attribute__((__always_inline__,__gnu_inline__))//g'
On Thursday, 7 March 2024 at 18:14:32 UTC, Gregor Mückl wrote:
2. C code referring to MSVC-specific compiler intrinsics. At
least InterlockedExchangeAdd, InterlockedExchangeAdd64 and
_stosb are such intrinsics. This is harder to resolve. There
are two ways forward here: either implement a shim
On Thursday, 7 March 2024 at 18:14:32 UTC, Gregor Mückl wrote:
1. Missing import libraries for Win32 API functions. Anything
starting with `__imp_` is a symbol that should be provided by a
DLL import library. MapViewOfFileNuma2 for example is provided
by onecore.lib in the Windows SDK, accordi
On Tuesday, 5 March 2024 at 00:20:36 UTC, Carl Sturtivant wrote:
On Monday, 4 March 2024 at 21:21:20 UTC, Carl Sturtivant wrote:
```
blah.obj: error LNK2019: unresolved external symbol _mul128
referenced in function MultiplyExtract128
blah.obj: error LNK2019: unresolved external symbol
__shift
On Monday, 4 March 2024 at 21:21:20 UTC, Carl Sturtivant wrote:
```
blah.obj: error LNK2019: unresolved external symbol _mul128
referenced in function MultiplyExtract128
blah.obj: error LNK2019: unresolved external symbol
__shiftright128 referenced in function MultiplyExtract128
blah.obj: error
On Monday, 26 February 2024 at 07:44:02 UTC, Dakota wrote:
I am use importC from linux, get this error:
```sh
/usr/include/x86_64-linux-gnu/bits/floatn-common.h(214): Error:
illegal combination of type specifiers
/usr/include/x86_64-linux-gnu/bits/floatn-common.h(251): Error:
illegal combinat
Dne so 20. 1. 2024 21:21 uživatel Renato via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> napsal:
> On Saturday, 20 January 2024 at 19:45:19 UTC, Daniel Kozak wrote:
> > On Sat, Jan 20, 2024 at 2:11 PM Renato via Digitalmars-d-learn
> > < digitalmars-d-learn@puremagic.com> wrote:
> >
>
On Saturday, 20 January 2024 at 19:45:19 UTC, Daniel Kozak wrote:
On Sat, Jan 20, 2024 at 2:11 PM Renato via Digitalmars-d-learn
< digitalmars-d-learn@puremagic.com> wrote:
Wow, fantastic feedback from lots of people, thanks so much!
...
> evilrat:
> There is another important difference, i
On Sat, Jan 20, 2024 at 2:11 PM Renato via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> Wow, fantastic feedback from lots of people, thanks so much!
> ...
>
> > evilrat:
> > There is another important difference, i quickly looked up D
> > associative array implementation and t
On Saturday, 20 January 2024 at 13:07:39 UTC, Renato wrote:
D overhead with the fastest compiler, LDC, compared with Rust:
```
1.0
1.707627119
1.919527897
1.954595186
1.351342502
1.556217748
```
Oh sorry, I only posted the rates for the Linux benchmark...
On Mac M1, for some reason, D was a
his table lookup is no in the hot path, so as
expected, it only seems to speed up slightly loading the
dictionary (which is good because D was behind for small inputs -
and even this tiny improvement could help D catch up).
To save from having to write a old-school verbose switch, i
suspect h
On Saturday, 20 January 2024 at 01:27:50 UTC, H. S. Teoh wrote:
On Sat, Jan 20, 2024 at 01:35:44AM +0100, Daniel Kozak via
Digitalmars-d-learn wrote: [...]
> Try addressing the points I wrote above and see if it
makes a
> difference.
I have tried it (all of it) even before you wrote i
On Sat, Jan 20, 2024 at 01:35:44AM +0100, Daniel Kozak via Digitalmars-d-learn
wrote:
[...]
>> Try addressing the points I wrote above and see if it makes a
>> difference.
>
>I have tried it (all of it) even before you wrote it here, because
>I have completely the same ideas, but
On Fri, Jan 19, 2024 at 4:44 PM H. S. Teoh via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> Taking a look at this code:
> ...
> Try addressing the points I wrote above and see if it makes a
> difference.
>
>
I have tried it (all of it) even before you wrote it here, because
On Friday, 19 January 2024 at 17:18:36 UTC, evilrat wrote:
On Friday, 19 January 2024 at 16:55:25 UTC, ryuukk_ wrote:
You do hash map lookup for every character in D, it's slow,
whereas in Rust you do it via pattern matching, java does the
same, pattern matching
Yet another reason to advoc
On Friday, 19 January 2024 at 08:57:40 UTC, Renato wrote:
Do you know why the whole thread seems to have disappeared??
There's a lot of good stuff in the thread, it would be a huge
shame to lose all that!
I agree! Thanks for posting your benchmarks, I thought your whole
benching setup was pre
On Friday, 19 January 2024 at 16:55:25 UTC, ryuukk_ wrote:
You do hash map lookup for every character in D, it's slow,
whereas in Rust you do it via pattern matching, java does the
same, pattern matching
Yet another reason to advocate for pattern matching in D and
switch as expression
Th
On Friday, 19 January 2024 at 13:40:39 UTC, Renato wrote:
On Friday, 19 January 2024 at 10:15:57 UTC, evilrat wrote:
On Friday, 19 January 2024 at 09:08:17 UTC, Renato wrote:
I forgot to mention: the Java version is using a Trie... and
it consistently beats the Rust numeric algorithm (which m
On Fri, Jan 19, 2024 at 01:40:39PM +, Renato via Digitalmars-d-learn wrote:
> On Friday, 19 January 2024 at 10:15:57 UTC, evilrat wrote:
[...]
> > Additionally if you comparing D by measuring DMD performance -
> > don't. It is valuable in developing for fast iterations, but it
> > lacks many m
On Friday, 19 January 2024 at 10:15:57 UTC, evilrat wrote:
On Friday, 19 January 2024 at 09:08:17 UTC, Renato wrote:
I forgot to mention: the Java version is using a Trie... and
it consistently beats the Rust numeric algorithm (which means
it's still faster than your D solution), but the Java
On Friday, 19 January 2024 at 10:15:57 UTC, evilrat wrote:
On Friday, 19 January 2024 at 09:08:17 UTC, Renato wrote:
I forgot to mention: the Java version is using a Trie... and
it consistently beats the Rust numeric algorithm (which means
it's still faster than your D solution), but the Java
On Friday, 19 January 2024 at 05:17:51 UTC, H. S. Teoh wrote:
On Thu, Jan 18, 2024 at 04:23:16PM +, Renato via
Digitalmars-d-learn wrote: [...]
Ok, last time I'm running this for someone else :D
```
Proc,Run,Memory(bytes),Time(ms)
===> ./rust
./rust,23920640,30
./rust,24018944,147
./rust,24
On Thu, Jan 18, 2024 at 04:23:16PM +, Renato via Digitalmars-d-learn wrote:
[...]
> Ok, last time I'm running this for someone else :D
>
> ```
> Proc,Run,Memory(bytes),Time(ms)
> ===> ./rust
> ./rust,23920640,30
> ./rust,24018944,147
> ./rust,24068096,592
> ./rust,24150016,1187
> ./rust,776601
On Wednesday, 17 January 2024 at 16:54:00 UTC, H. S. Teoh wrote:
On Wed, Jan 17, 2024 at 07:57:02AM -0800, H. S. Teoh via
Digitalmars-d-learn wrote: [...]
I'll push the code to github.
[...]
Here:
https://github.com/quickfur/prechelt/blob/master/encode_phone.d
T
BTW here's you main funct
On Wednesday, 17 January 2024 at 16:54:00 UTC, H. S. Teoh wrote:
On Wed, Jan 17, 2024 at 07:57:02AM -0800, H. S. Teoh via
Digitalmars-d-learn wrote: [...]
I'll push the code to github.
[...]
Here:
https://github.com/quickfur/prechelt/blob/master/encode_phone.d
T
Ok, last time I'm running
On Wednesday, 17 January 2024 at 16:30:08 UTC, H. S. Teoh wrote:
On Wed, Jan 17, 2024 at 07:19:39AM +, Renato via
Digitalmars-d-learn wrote: [...]
But pls run the benchmarks yourself as I am not going to keep
running it for you, and would be nice if you posted your
solution on a Gist for ex
On Wed, Jan 17, 2024 at 07:57:02AM -0800, H. S. Teoh via Digitalmars-d-learn
wrote:
[...]
> I'll push the code to github.
[...]
Here: https://github.com/quickfur/prechelt/blob/master/encode_phone.d
T
--
Why do conspiracy theories always come from the same people??
On Wed, Jan 17, 2024 at 07:19:39AM +, Renato via Digitalmars-d-learn wrote:
[...]
> But pls run the benchmarks yourself as I am not going to keep running
> it for you, and would be nice if you posted your solution on a Gist
> for example, pasting lots of code in the forum makes it difficult to
On Wed, Jan 17, 2024 at 07:19:39AM +, Renato via Digitalmars-d-learn wrote:
> On Tuesday, 16 January 2024 at 22:13:55 UTC, H. S. Teoh wrote:
> > used for the recursive calls. Getting rid of the .format ought to
> > speed it up a bit. Will try that now...
> >
>
> That will make no difference f
On Wednesday, 17 January 2024 at 11:56:19 UTC, evilrat wrote:
On Wednesday, 17 January 2024 at 11:20:14 UTC, Renato wrote:
That means the input file is still not ASCII (or UTF-8) as it
should. Java is reading files with the ASCII encoding so it
should've worked fine.
It seems that it is onl
On Wednesday, 17 January 2024 at 11:20:14 UTC, Renato wrote:
That means the input file is still not ASCII (or UTF-8) as it
should. Java is reading files with the ASCII encoding so it
should've worked fine.
It seems that it is only works with ASCII encoding though.
toathaydes/prechelt-phone-number-encoding/blob/master/benchmark.sh#L31):
```
java -cp "build/util" util.GeneratePhoneNumbers 1000 >
phones_1000.txt
```
Perhaps using this option when running Java will help:
```
java -DFile.Encoding=UTF-8 ...
```
I've used powershell env
ark.sh#L31):
```
java -cp "build/util" util.GeneratePhoneNumbers 1000 >
phones_1000.txt
```
Perhaps using this option when running Java will help:
```
java -DFile.Encoding=UTF-8 ...
```
I've used powershell env var to set output to utf8, D version now
works but java doesn't
atePhoneNumbers 1000 >
phones_1000.txt
```
Perhaps using this option when running Java will help:
```
java -DFile.Encoding=UTF-8 ...
```
On Wednesday, 17 January 2024 at 09:15:02 UTC, evilrat wrote:
On Wednesday, 17 January 2024 at 07:11:02 UTC, Renato wrote:
If you want to check your performance, you know you can run
the `./benchmark.sh` yourself?
Out of curiosity I've tried to manually run this on Windows and
it seems that
On Wednesday, 17 January 2024 at 07:06:25 UTC, Renato wrote:
On Tuesday, 16 January 2024 at 22:15:04 UTC, Siarhei Siamashka
wrote:
On Tuesday, 16 January 2024 at 21:15:19 UTC, Renato wrote:
It's a GC allocations fest. Things like this make it slow:
```diff
{
-string digit = [digit
On Wednesday, 17 January 2024 at 07:11:02 UTC, Renato wrote:
If you want to check your performance, you know you can run the
`./benchmark.sh` yourself?
Out of curiosity I've tried to manually run this on Windows and
it seems that Java generator for these numbers files is "broken",
the resul
On Tuesday, 16 January 2024 at 22:13:55 UTC, H. S. Teoh wrote:
used for the recursive calls. Getting rid of the .format ought
to speed it up a bit. Will try that now...
That will make no difference for the `count` option which is
where your solution was very slow. To run the slow test manual
On Tuesday, 16 January 2024 at 22:15:04 UTC, Siarhei Siamashka
wrote:
On Tuesday, 16 January 2024 at 21:15:19 UTC, Renato wrote:
For the record (I already posted this on GitHub)... here's [my
current fastest
solution](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/dlang-k
On Tue, Jan 16, 2024 at 10:15:04PM +, Siarhei Siamashka via
Digitalmars-d-learn wrote:
> On Tuesday, 16 January 2024 at 21:15:19 UTC, Renato wrote:
[...]
> > ... what I am really curious about is what the code I wrote is doing
> > wrong that causes it to run 4x slower than Rust despite doing "
On Tuesday, 16 January 2024 at 21:15:19 UTC, Renato wrote:
For the record (I already posted this on GitHub)... here's [my
current fastest
solution](https://github.com/renatoathaydes/prechelt-phone-number-encoding/blob/dlang-key-hash-incremental/src/d/src/dencoder.d) time using the same algorithm
On Tue, Jan 16, 2024 at 09:15:19PM +, Renato via Digitalmars-d-learn wrote:
> On Tuesday, 16 January 2024 at 20:34:48 UTC, H. S. Teoh wrote:
> > On Tue, Jan 16, 2024 at 12:28:49PM -0800, H. S. Teoh via
> > Digitalmars-d-learn wrote: [...]
> > > Anyway, I've fixed the problem, now my program pro
On Tuesday, 16 January 2024 at 21:15:19 UTC, Renato wrote:
I can't explain why it's so incredibly fast, specially for the
`count` case. I tried using the same hashing function on my
solution, but that didn't really help me!
That's dynamic programming with memoization. Ba
for the
`count` case. I tried using the same hashing function on my
solution, but that didn't really help me!
Pretty cool to see different solutions to the problem, but I'm
still curious to know where the solution I wrote is being slow
compared to Rust which is using identical, to my u
On Tue, Jan 16, 2024 at 12:28:49PM -0800, H. S. Teoh via Digitalmars-d-learn
wrote:
[...]
> Anyway, I've fixed the problem, now my program produces the exact same
> output as Renato's repo. Code is posted below.
[...]
Oops, forgot to actually paste the code. Here it is:
-
On Tue, Jan 16, 2024 at 06:54:56PM +, Renato via Digitalmars-d-learn wrote:
> On Tuesday, 16 January 2024 at 16:56:04 UTC, Siarhei Siamashka wrote:
[...]
> > You are not allowed to emit "1" as the first token in the output as
> > long as there are any dictionary word matches at that position. T
On Tuesday, 16 January 2024 at 16:56:04 UTC, Siarhei Siamashka
wrote:
On Tuesday, 16 January 2024 at 15:50:35 UTC, H. S. Teoh wrote:
Unfortunately there seems to be some discrepancy between the
output I got and the prescribed output in your repository. For
example, in your output the number 155
On Tuesday, 16 January 2024 at 15:50:35 UTC, H. S. Teoh wrote:
Unfortunately there seems to be some discrepancy between the
output I got and the prescribed output in your repository. For
example, in your output the number 1556/0 does not have an
encoding, but isn't "1 Mai 0" a valid encoding ac
P.S. Compiling my program with `ldc -O2`, it runs so fast that I
couldn't measure any meaningful running time that's greater than startup
overhead. So I wrote a helper program to generate random phone numbers
up to 50 characters long, and found that it could encode 1 million phone
numbers in 2.2 s
On Tue, Jan 16, 2024 at 07:50:35AM -0800, H. S. Teoh via Digitalmars-d-learn
wrote:
[...]
> Unfortunately there seems to be some discrepancy between the output I
> got and the prescribed output in your repository. For example, in your
> output the number 1556/0 does not have an encoding, but isn't
On Mon, Jan 15, 2024 at 08:10:55PM +, Renato via Digitalmars-d-learn wrote:
> On Monday, 15 January 2024 at 01:10:14 UTC, Sergey wrote:
> > On Sunday, 14 January 2024 at 17:11:27 UTC, Renato wrote:
> > > If anyone can find any flaw in my methodology or optmise my code so
> > > that it can still
On Monday, 15 January 2024 at 01:10:14 UTC, Sergey wrote:
On Sunday, 14 January 2024 at 17:11:27 UTC, Renato wrote:
If anyone can find any flaw in my methodology or optmise my
code so that it can still get a couple of times faster,
approaching Rust's performance, I would greatly appreciate
tha
On Sunday, 14 January 2024 at 17:11:27 UTC, Renato wrote:
If anyone can find any flaw in my methodology or optmise my
code so that it can still get a couple of times faster,
approaching Rust's performance, I would greatly appreciate
that! But for now, my understanding is that the most promising
On Sunday, 14 January 2024 at 10:02:58 UTC, Jordan Wilson wrote:
On Saturday, 13 January 2024 at 11:03:42 UTC, Renato wrote:
I like to use a phone encoding problem to determine the
strenghtness and weaknesses of programming languages because
this problem is easy enough I can write solutions in
On Saturday, 13 January 2024 at 23:20:32 UTC, Sergey wrote:
On Saturday, 13 January 2024 at 19:35:57 UTC, Renato wrote:
On Saturday, 13 January 2024 at 17:00:58 UTC, Anonymouse wrote:
On Saturday, 13 January 2024 at 12:55:27 UTC, Renato wrote:
[...]
I will have to try it... I thought that `Big
On Saturday, 13 January 2024 at 11:03:42 UTC, Renato wrote:
I like to use a phone encoding problem to determine the
strenghtness and weaknesses of programming languages because
this problem is easy enough I can write solutions in any
language in a few hours, but complex enough to exercise lots
On Saturday, 13 January 2024 at 23:20:32 UTC, Sergey wrote:
I would suggest to rewrite in the same way as Rust implemented.
Probably you would like to try:
[...]
I would strongly argue for profiling first instead of optimising
based on conjecture. If you profile you have solid evidence on
wha
On Saturday, 13 January 2024 at 19:35:57 UTC, Renato wrote:
On Saturday, 13 January 2024 at 17:00:58 UTC, Anonymouse wrote:
On Saturday, 13 January 2024 at 12:55:27 UTC, Renato wrote:
[...]
I will have to try it... I thought that `BigInt` was to blame
for the slowness (from what I could read f
On Saturday, 13 January 2024 at 17:00:58 UTC, Anonymouse wrote:
On Saturday, 13 January 2024 at 12:55:27 UTC, Renato wrote:
[...]
Not a great profiling experience :). Anyone has a better
suggestion to "parse" the trace file?
As a drive-by suggestion and I hope it doesn't derail anything,
but
On Saturday, 13 January 2024 at 12:55:27 UTC, Renato wrote:
[...]
Not a great profiling experience :). Anyone has a better
suggestion to "parse" the trace file?
As a drive-by suggestion and I hope it doesn't derail anything,
but if you have the opportunity to run it on linux, have you
tried
On Saturday, 13 January 2024 at 11:03:42 UTC, Renato wrote:
I tried to profile the D code but the profiler seems to be
broken on my OS (Mac):
I profiled it on Linux and stored [the trace.log
file](https://gist.github.com/renatoathaydes/fd8752ed81b0cf792ed7ef5aa3d68acd) on a public Gist.
I like to use a phone encoding problem to determine the
strenghtness and weaknesses of programming languages because this
problem is easy enough I can write solutions in any language in a
few hours, but complex enough to exercise lots of interesting
parts of the language.
You can check [my in
ould do for my scope. I'm much more confident using this
compared to the naked `shared` AA I started with.
Thanks everyone for the help.
On Tuesday, 2 January 2024 at 11:39:12 UTC, Anonymouse wrote:
On Tuesday, 2 January 2024 at 11:05:33 UTC, user1234 wrote:
Do not use `shared` AA. Use `__gshared` + sync primitives.
`shared` AA will lead to all sort of bugs:
- https://issues.dlang.org/show_bug.cgi?id=20484#c1
- https://issues.d
On Tuesday, January 2, 2024 3:41:55 AM MST Anonymouse via Digitalmars-d-learn
wrote:
> On Monday, 1 January 2024 at 19:49:28 UTC, Jonathan M Davis wrote:
> > [...]
>
> Thank you. Yes, `Foo` is a class for the purposes of inheritance
> -- I left that out of the example.
>
> So a completely valid so
On Tuesday, January 2, 2024 4:39:12 AM MST Anonymouse via Digitalmars-d-learn
wrote:
> On Tuesday, 2 January 2024 at 11:05:33 UTC, user1234 wrote:
> > Do not use `shared` AA. Use `__gshared` + sync primitives.
> > `shared` AA will lead to all sort of bugs:
> >
> > - https://issues.dlang.org/show_b
On Tuesday, 2 January 2024 at 10:41:55 UTC, Anonymouse wrote:
On Monday, 1 January 2024 at 19:49:28 UTC, Jonathan M Davis
wrote:
[...]
Thank you. Yes, `Foo` is a class for the purposes of
inheritance -- I left that out of the example.
So a completely valid solution is to write a struct wrap
On Tuesday, 2 January 2024 at 11:05:33 UTC, user1234 wrote:
Do not use `shared` AA. Use `__gshared` + sync primitives.
`shared` AA will lead to all sort of bugs:
- https://issues.dlang.org/show_bug.cgi?id=20484#c1
- https://issues.dlang.org/show_bug.cgi?id=17088
- https://issues.dlang.org/show_
On Monday, 1 January 2024 at 15:48:16 UTC, Anonymouse wrote:
I have a `shared string[int]` AA that I access from two
different threads. The function I spawn to start the second
thread takes the AA as an argument.
[...]
What is the common solution here? Do I add a module-level
`Object thing`
On Monday, 1 January 2024 at 19:49:28 UTC, Jonathan M Davis wrote:
[...]
Thank you. Yes, `Foo` is a class for the purposes of inheritance
-- I left that out of the example.
So a completely valid solution is to write a struct wrapper
around an AA of the type I need, overload the required ope
On Monday, 1 January 2024 at 15:48:16 UTC, Anonymouse wrote:
What is the common solution here? Do I add a module-level
`Object thing` and move everything accessing the AA into
`synchronized(.thing)` statements? Or maybe add a `shared
static` something to `Foo` and synchronise with
`synchronize
On Monday, January 1, 2024 8:48:16 AM MST Anonymouse via Digitalmars-d-learn
wrote:
> I have a `shared string[int]` AA that I access from two different
> threads. The function I spawn to start the second thread takes
> the AA as an argument.
>
> ```d
> class Foo
> {
> shared string[int] bucke
I have a `shared string[int]` AA that I access from two different
threads. The function I spawn to start the second thread takes
the AA as an argument.
```d
class Foo
{
shared string[int] bucket;
Tid worker;
}
void workerFn(shared string[int] bucket)
{
while (true)
{
//
On Saturday, 2 December 2023 at 19:13:18 UTC, Vino B wrote:
Hi All,
Request your help in understanding the below program, with
the below program I can allocate 8589934592(8GB) it prints the
length 8589934592(8GB) where as my laptop has only 4 GB so the
confusion is that how can this
On Saturday, 2 December 2023 at 19:13:18 UTC, Vino B wrote:
Hi All,
Request your help in understanding the below program, with
the below program I can allocate 8589934592(8GB) it prints the
length 8589934592(8GB) where as my laptop has only 4 GB so the
confusion is that how can this
Hi All,
Request your help in understanding the below program, with the
below program I can allocate 8589934592(8GB) it prints the length
8589934592(8GB) where as my laptop has only 4 GB so the confusion
is that how can this program allocate 8GB RAM when I have only
4GB of RAM installed
On Friday, 6 October 2023 at 13:44:14 UTC, d007 wrote:
I am search for a fast 128bit integer ucent boolfilter, used
for server side duplicate request filter.
Is 128bit boolfilter a doable thing? or it will not work or
will be much more slow compare to 64 bit solution?
Can you describe or gi
I am search for a fast 128bit integer ucent boolfilter, used for
server side duplicate request filter.
I can seed there is https://github.com/MartinNowak/bloom, only
accept size_t as key.
Is there some library support 128bit integer boolfilter ? C or
C++ or rust is ok for me.
Is 128bit
1 - 100 of 1008 matches
Mail list logo
