On Wed, Dec 14, 2022 at 07:38:51PM +0000, torhu via Digitalmars-d wrote:
> On Wednesday, 14 December 2022 at 01:47:29 UTC, Steven Schveighoffer wrote:
> > 
> > ```d
> > void main() @nogc
> > {
> >    import std.conv;
> >    auto v = "42".to!int;
> > }
> > ```
> 
> 
> I have been wondering why there isn't a basic variation like this available:
> 
> ```d
> auto i = "42".toOr!int(-1);
> auto s = i.toOr!string(null);
> ```

This would be a nice addition to Phobos IMO.  Though we should think of a better name for it. :-P


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.

On 16/12/2022 12:21 AM, IGotD- wrote:
> All those ideas and tricks are based on that you in some way should avoid or circumvent the garbage collector. Then the question is, how good is a computer algorithm if you are supposed to avoid it all the time?

Like all algorithms, if you misuse it its going to be bad.

Calling into the GC unnecessarily when you care about performance is misuse.

On Thursday, 15 December 2022 at 11:21:56 UTC, IGotD- wrote:
> ... Then the question is, how good is a computer algorithm if you are supposed to avoid it all the time?
> ...

To be honest I don't think people generally are bothered with this. I mean when I write my batch programs to process something in D or C# I don't even think about the GC stopping or whatever, most of the time it will process some data in a reasonable time so I'm OK.

The other day I had to write a program to comparable the sync between 2 different databases and check the differences over millions of lines. The program ran very fast and gave the result expected in a very reasonable time.

Of course in some areas this may hurt (Like games) and then you will need to think of ways to avoid it.

But for example imagine a drawing app, let's say you're filling an area and during this process the GC stops for a second. I mean will this make so much difference?

Yes some people will notice this, but the majority will not even think or know this happened.

Where I work (Which is a big Health Insurance in my country), our main language is C# and we process millions of data every day, apps, web apps etc. And nobody is complaining too much about the delay in our operations.

Matheus.

On Thursday, 15 December 2022 at 11:56:31 UTC, matheus wrote:
>
> To be honest I don't think people generally are bothered with this. I mean when I write my batch programs to process something in D or C# I don't even think about the GC stopping or whatever, most of the time it will process some data in a reasonable time so I'm OK.
>

Majority of applications are so small and have little performance requirements that it doesn't matter. It starts to matter when you have web services, games etc. For example if you reduce the memory consumption, perhaps you don't need to buy/hire that extra infrastructure which cost money.


> Where I work (Which is a big Health Insurance in my country), our main language is C# and we process millions of data every day, apps, web apps etc. And nobody is complaining too much about the delay in our operations.
>

The default GC in C# is generational which is also a workaround of the inefficiency of the algorithm. C# has at least the luxury to use several different types of GC which might be more of them in the future.

I'm amazed how much the tracing GC is used in the computer industry despite its complexity and drawbacks. When will the time come when the tracing GC no longer scales with increasing memory consumption?

On Thursday, 15 December 2022 at 12:36:59 UTC, IGotD- wrote:
> I'm amazed how much the tracing GC is used in the computer industry despite its complexity and drawbacks. When will the time come when the tracing GC no longer scales with increasing memory consumption?

We will most likely see coprocessors working on regular memory, and like now, people will use no-gc libraries for the low latency heavy lifting. Another hardware solution would be to let cores have local memory, then people will switch to pushing data as values through a pipeline and avoid references. That would scale well, but requires developers to switch to a new more "functional" mindset.

Anyway, concurrent collectors that don't stop the world are not as bad if you add hardware capabilities that prevents the caches for being flushed and the data-bus from being saturated. You could have a separate hardware-cache for book-keeping tasks and just slowly scan memory in the background rather than the hit-and-run approach.

Besides, most applications don't really need the full capabilities of modern hardware so the users don't mind applications being slow as they don't "understand" that they are actually slow… :-) That's what makes javascript and dart competitive for application development.