Re: Life in the Fast Lane (@nogc blog post)

[Joakim via Digitalmars-d-announce]

On Friday, 16 June 2017 at 18:26:15 UTC, Joakim wrote:

On Friday, 16 June 2017 at 13:51:18 UTC, Mike Parker wrote:
I've been meaning to get this done for weeks but have had a 
severe case of writer's block. The fact that I had no other 
posts ready to go this week and no time to write anything at 
all motivated me to make time for it and get it done anyway. 
My wife didn't complain when I told her I had to abandon our 
regular bedtime Netflix time block (though she did extract a 
concession that I have no vote in the next series we watch). 
Thanks to Vladimir, Guillaume, and Steve, for their great 
feedback on such short notice. Their assistance kept the blog 
from going quiet this week.


The blog:
https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/

Reddit:
https://www.reddit.com/r/programming/comments/6hmlfq/life_in_the_fast_lane_using_d_without_the_gc/


Nicely written.  I never bothered to look into this GC 
fine-tuning, as I don't need that level of optimization, but I 
finally have some idea of how this works.


And people have noticed, it's about to hit the top 10 most-liked 
proggit links of the last 7 days:


https://www.reddit.com/r/programming/top/?sort=top=week

One typo I forgot to mention earlier, where you wrote "aren't 
likey."

Re: Lubeck: Hight Level Linear Algebra for Dlang

[data pulverizer via Digitalmars-d-announce]

On Tuesday, 13 June 2017 at 08:26:20 UTC, 9il wrote:

Hi

I am pleased to announce the Lubeck [1] linear algebra library 
for Dlang.

It is very easy to use and it has been tested in real world.

The following functionality is implemented:

1. `mtimes` - General matrix-matrix, row-matrix, matrix-column, 
and row-column multiplications.


2. `mldivide` - Solve systems of linear equations AX = B for X. 
Computes minimum-norm solution to a linear least squares problem

if A is not a square matrix.

3. `inv` - Inverse of matrix.

4. `svd` - Singular value decomposition.

5. `pca` - Principal component analysis of raw data.

6. `pinv` - Moore-Penrose pseudoinverse of matrix.

7. `det`/`detSymmetric` - General/symmetric matrix determinant.

8. `eigSymmetric` - Eigenvalues and eigenvectors of symmetric 
matrix.



The package depends on mir-blas, mir-lapack, and mir-algorithm.


This work has been sponsored by Symmetry Investments[7] and 
Kaleidic Associates[8].


Best regards,
Ilya


This is great news! as I said in a previous discussion 
(https://forum.dlang.org/post/nrbcrpnvcrlqvpqho...@forum.dlang.org) a library like this is pretty important for numerical computing in D and together with Mir can form the basis of implementing algorithms for a myriad of applications in analysis.


Many thanks to all those involved!

Re: Life in the Fast Lane (@nogc blog post)

[Adam D. Ruppe via Digitalmars-d-announce]

On Saturday, 17 June 2017 at 16:59:56 UTC, Dukc wrote:
If that Walter's DIP about reference-counted exceptions gets 
trough it should ease problem like that quite a bit.


Possibly. There's a lot of solutions to the exception thing 
though, and it doesn't actually bother me if you see @nogc as 
being very niche because you can just use one of those solutions 
today. (most of them depend simply on the catching code calling 
some disposal function, or living with a (possibly temporary) 
leak. Aside from that, the *most* you have to do is just `throw 
make!Exception` instead of `throw new Exception` and problem 
solved).


Didn't Don Clugston say about something at some Dconf that it 
must trigger allocation "not hardly ever, NEVER"? So there's a 
real need even for the rigid @nogc, albeit a niche one.


Yes, there are a few cases for it, but most people on reddit 
aren't one of them.


It reminds me of the "web scale" thing. "but can this handle 1 
million hits per second?" Probably not, but you also almost 
certainly going to need to... and if you do, the company will 
surely have the budget to hire a whole team of full time people 
to develop some specialized solution to their problem.


The D language should certainly never get in the way of those 
specialized solutions, whether scaling, or low latency 
audio/bidding, or whatever else, but I'm not convinced it needs 
to support them all out of the box either - and the average D 
user (or web developer in general) certainly doesn't have to 
worry.

Re: Life in the Fast Lane (@nogc blog post)

[Adam D. Ruppe via Digitalmars-d-announce]

On Saturday, 17 June 2017 at 13:09:42 UTC, Guillaume Piolat wrote:
As a counterpoint: It's true that it's a bit niche, but when 
you have "no gc" then @nogc really helps with peace of mind 
(only one allocation and you may crash).


Yes, when you actually need it it might be helpful, and then the 
associated niche libraries might use it too.


Of course, you can still lie about the attributes...

Re: Life in the Fast Lane (@nogc blog post)

[Dukc via Digitalmars-d-announce]

On Saturday, 17 June 2017 at 13:05:50 UTC, Adam D. Ruppe wrote:
The reason writeln fails @nogc is that it *might* throw an 
exception with most args if stdout is closed or something.


Perfect example of an *extremely* rare case failing @nogc's 
ridiculously strict requirements.


If that Walter's DIP about reference-counted exceptions gets 
trough it should ease problem like that quite a bit.


And as he said, memory-safe programming is not the problem 
-verifying the safety is. I think it is the same with GC.


Didn't Don Clugston say about something at some Dconf that it 
must trigger allocation "not hardly ever, NEVER"? So there's a 
real need even for the rigid @nogc, albeit a niche one.

Re: Life in the Fast Lane (@nogc blog post)

[Johannes Pfau via Digitalmars-d-announce]

Am Fri, 16 Jun 2017 13:51:18 +
schrieb Mike Parker :

> I've been meaning to get this done for weeks but have had a 
> severe case of writer's block. The fact that I had no other posts 
> ready to go this week and no time to write anything at all 
> motivated me to make time for it and get it done anyway. My wife 
> didn't complain when I told her I had to abandon our regular 
> bedtime Netflix time block (though she did extract a concession 
> that I have no vote in the next series we watch). Thanks to 
> Vladimir, Guillaume, and Steve, for their great feedback on such 
> short notice. Their assistance kept the blog from going quiet 
> this week.
> 
> The blog:
> https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/
> 
> Reddit:
> https://www.reddit.com/r/programming/comments/6hmlfq/life_in_the_fast_lane_using_d_without_the_gc/
> 
> 

Nice blog post!

> Let’s imagine a hypothetical programmer named J.P. who, for reasons
> he considers valid, has decided he would like to avoid garbage
> collection completely in his D program. He has two immediate options.

I think I might know that hypothetical programmer ;-)

-- Johannes

Re: Life in the Fast Lane (@nogc blog post)

[ketmar via Digitalmars-d-announce]

Guillaume Piolat wrote:


On Saturday, 17 June 2017 at 13:05:50 UTC, Adam D. Ruppe wrote:


This is why I consider @nogc to be an *extremely* niche feature and 
generally harmful. It makes things look a lot harder than it really is - 
people confuse `@nogc` with "no gc". Instead, I suggest just minding the 
list and using runtime profiling and debugging to ensure your needs are 
met in actual practice.




As a counterpoint: It's true that it's a bit niche, but when you have "no 
gc" then @nogc really helps with peace of mind (only one allocation and 
you may crash).


yeah, it helps a little... in (let's be honest) rare situations where you 
really want to be *completely* free of any possible gc allocation. in most 
real-life scenarios you're ok with "mostly gc-free, except for exceptional 
cases" (like writeln, for example), and you have no way to express it. i 
end up not using @nogc at all (except on simple `return a` getters), 
despite the fact that many of my code rarely allocates.


there should be a way to say "i don't want gc on this code path, but it is 
ok for this one" (like throwing), without resorting to dirty tricks with 
casting and lambdas. something like `@raregc` ;-).


but then, how we should define "rare"? that attribute will quickly become 
useless, as people will mark arbitrary code with it.


so, `@nogc` is mostly useless IRL (you can't even `enforce` with it), and 
`@raregc` will become useless if introduced. and the sole reason (as i see 
it) of introducing `@nogc` was to please people complaining about gc 
allocations, no matter how often they're done, and on which code path. i 
myself see it as "PR design", which attracts people only to make them find 
that using D with `@nogc` is a PITA, due to `@nogc` being too restrictive.


what `@nogc` *really* does now is dividing codebases into "i will do all 
kind of dirty tricks to avoid GC at all costs, even if it is not really 
necessary", and into "ah, screw it, i don't care". to me, it looks like 
`@nogc` does more bad than good now.

Re: Life in the Fast Lane (@nogc blog post)

[Adam D. Ruppe via Digitalmars-d-announce]

On Saturday, 17 June 2017 at 07:03:53 UTC, Petar Kirov 
[ZombineDev] wrote:
2. However, there's this long list of things that you have to 
avoid.


There's like 10 things to avoid in the language itself: 
http://dlang.org/spec/garbage.html#op_involving_gc


and most of them are obviously array stuff so it is easy to 
remember - and easy to skip with a simple array helper... which 
is often a useful optimization too, make one that uses stack 
space! You can write one in about 15 minutes.



Now, @nogc is a bit more restrictive since it isn't just avoiding 
GC calls it avoids the *possibility* of GC calls. Even if it 
would only actually run one in a million times at which point you 
want the program to die anyway @nogc still bans it. Even if 
it would never actually run, but some leaf function somewhere 
wrote `int getLength() { return _length; }` instead of `int 
getLength() @nogc pure const @safe nothrow { return _length; 
}`... it obviously doesn't run the gc, but still fails @nogc for 
its entire call tree.



This is why I consider @nogc to be an *extremely* niche feature 
and generally harmful. It makes things look a lot harder than it 
really is - people confuse `@nogc` with "no gc". Instead, I 
suggest just minding the list and using runtime profiling and 
debugging to ensure your needs are met in actual practice.


3. So while this "@nogc" is technically possible you loose so 
much of the language that you're better of with C++ (where e.g. 
"cout" just works*).


of course you could always `printf` lol.

The reason writeln fails @nogc is that it *might* throw an 
exception with most args if stdout is closed or something.


Perfect example of an *extremely* rare case failing @nogc's 
ridiculously strict requirements.

Re: Life in the Fast Lane (@nogc blog post)

[Guillaume Piolat via Digitalmars-d-announce]

On Saturday, 17 June 2017 at 13:05:50 UTC, Adam D. Ruppe wrote:


This is why I consider @nogc to be an *extremely* niche feature 
and generally harmful. It makes things look a lot harder than 
it really is - people confuse `@nogc` with "no gc". Instead, I 
suggest just minding the list and using runtime profiling and 
debugging to ensure your needs are met in actual practice.




As a counterpoint: It's true that it's a bit niche, but when you 
have "no gc" then @nogc really helps with peace of mind (only one 
allocation and you may crash).

Re: Life in the Fast Lane (@nogc blog post)

[Eugene Wissner via Digitalmars-d-announce]

On Saturday, 17 June 2017 at 08:51:04 UTC, Mike Parker wrote:
On Saturday, 17 June 2017 at 07:03:53 UTC, Petar Kirov 
[ZombineDev] wrote:



The right answer is three fold:
A) Examples of idiomatic D code - generic functions agnostic 
about the memory management strategy like range algorithms;


B) Having solid tools at the language-level for implementing 
correct and relatively easy-to-use library primitives like 
smart pointers and containers - @safe + pure + scope.


C) Maintaining a list of functions/modules/third-party 
libraries that are usable in @nogc land.


But most of all, the focus should be on productivity and 
ease-of-use, because otherwise people tend to get the 
impression: TL;DR this is too complicated for me -> I can't 
use D without the GC -> Using D without the GC is not feasible.


Thanks! I agree that we need a range of posts on the GC. That's 
the whole point of the series. I have a set of posts I can 
write on topics within my current realm of knowledge, or that I 
can beef up on when the time comes, but beyond that I'm not the 
right guy to author some of the posts that need to be written. 
I haven't familiarized myself with all the corners, nor have I 
written any code that required me to push the boundaries or 
explore the possibilities.


A while back, I posted an announcement here explaining my goals 
with the GC series and asking for contributors. Aside from 
Atila's automem post, I haven't gotten any takers yet. I can, 
if need be, eventually write many of the posts I'd like to 
have, but that requires making time to familiarize myself with 
the topics. Such posts will also compete with those I plan to 
write on other topics.


So, in the interest of saving me a bit of time, I invite you 
and anyone who's willing to share their experiences and 
expertise with the GC. I'll happily publish any post that 
demonstrates allocation strategies, lifetime management, 
optimizations, or just generally helps to clear up 
misconceptions.


Hm. In my personal projects I'm using D exclusively as a 
high-level C, so without the GC. I have also Unique and 
RefCounted, that are very new and not so well tested. On the 
other hand I've written a good set of containers, that are 
completely @nogc and are different from std and EMSI containers. 
I would be interested to write a few lines about container usage, 
why not built-in arrays and so on. But I should say I need some 
time, I have currently enough to write at the semester's end :)

Re: Life in the Fast Lane (@nogc blog post)

[Mike Parker via Digitalmars-d-announce]

On Saturday, 17 June 2017 at 07:03:53 UTC, Petar Kirov 
[ZombineDev] wrote:



The right answer is three fold:
A) Examples of idiomatic D code - generic functions agnostic 
about the memory management strategy like range algorithms;


B) Having solid tools at the language-level for implementing 
correct and relatively easy-to-use library primitives like 
smart pointers and containers - @safe + pure + scope.


C) Maintaining a list of functions/modules/third-party 
libraries that are usable in @nogc land.


But most of all, the focus should be on productivity and 
ease-of-use, because otherwise people tend to get the 
impression: TL;DR this is too complicated for me -> I can't use 
D without the GC -> Using D without the GC is not feasible.


Thanks! I agree that we need a range of posts on the GC. That's 
the whole point of the series. I have a set of posts I can write 
on topics within my current realm of knowledge, or that I can 
beef up on when the time comes, but beyond that I'm not the right 
guy to author some of the posts that need to be written. I 
haven't familiarized myself with all the corners, nor have I 
written any code that required me to push the boundaries or 
explore the possibilities.


A while back, I posted an announcement here explaining my goals 
with the GC series and asking for contributors. Aside from 
Atila's automem post, I haven't gotten any takers yet. I can, if 
need be, eventually write many of the posts I'd like to have, but 
that requires making time to familiarize myself with the topics. 
Such posts will also compete with those I plan to write on other 
topics.


So, in the interest of saving me a bit of time, I invite you and 
anyone who's willing to share their experiences and expertise 
with the GC. I'll happily publish any post that demonstrates 
allocation strategies, lifetime management, optimizations, or 
just generally helps to clear up misconceptions.

Re: Life in the Fast Lane (@nogc blog post)

[via Digitalmars-d-announce]

On Friday, 16 June 2017 at 13:51:18 UTC, Mike Parker wrote:
I've been meaning to get this done for weeks but have had a 
severe case of writer's block. The fact that I had no other 
posts ready to go this week and no time to write anything at 
all motivated me to make time for it and get it done anyway. My 
wife didn't complain when I told her I had to abandon our 
regular bedtime Netflix time block (though she did extract a 
concession that I have no vote in the next series we watch). 
Thanks to Vladimir, Guillaume, and Steve, for their great 
feedback on such short notice. Their assistance kept the blog 
from going quiet this week.


The blog:
https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/

Reddit:
https://www.reddit.com/r/programming/comments/6hmlfq/life_in_the_fast_lane_using_d_without_the_gc/


Thanks for the nice write-up, Mike! Posts like this one really 
help clear many misconceptions about the language. Keep them 
coming!


I think the next blog should address what's possible without the 
GC and what features of the language/library make it more 
productive than languages like C and C++ even in @nogc code. I'm 
getting the impression that people on Reddit (and in general 
people inexperienced with language) see this:

1. Yes, it's *technically* possible to use D without the GC.
2. However, there's this long list of things that you have to 
avoid.
3. So while this "@nogc" is technically possible you loose so 
much of the language that you're better of with C++ (where e.g. 
"cout" just works*).


* For some unspecified meaning of working.

And also comments like:
Reading this article makes me realize how naturally C++ 
(particularly C++11) does without a GC. It's the right tool for 
the job if your program must not have a GC.


Which obviously can't be further from the truth. That's why we 
need a systematic answer to how to use D effectively without the 
GC.


The right answer is three fold:
A) Examples of idiomatic D code - generic functions agnostic 
about the memory management strategy like range algorithms;


B) Having solid tools at the language-level for implementing 
correct and relatively easy-to-use library primitives like smart 
pointers and containers - @safe + pure + scope.


C) Maintaining a list of functions/modules/third-party libraries 
that are usable in @nogc land.


But most of all, the focus should be on productivity and 
ease-of-use, because otherwise people tend to get the impression: 
TL;DR this is too complicated for me -> I can't use D without the 
GC -> Using D without the GC is not feasible.