http://codecapsule.com/2014/02/12/coding-for-ssds-part-6-a-summary-what-every-programmer-should-know-about-solid-state-drives/

An interesting article. Anyone want to see if there are any modifications we should make to std.stdio to work better with SSDs? (Such as changing the buffer sizes.)

On Friday, 24 April 2015 at 08:27:06 UTC, Walter Bright wrote:
> http://codecapsule.com/2014/02/12/coding-for-ssds-part-6-a-summary-what-every-programmer-should-know-about-solid-state-drives/
>
> An interesting article. Anyone want to see if there are any modifications we should make to std.stdio to work better with SSDs? (Such as changing the buffer sizes.)

Part 3 covers read/write optimizations in specific for anyone interested in reading.

On Friday, 24 April 2015 at 08:27:06 UTC, Walter Bright wrote:
> http://codecapsule.com/2014/02/12/coding-for-ssds-part-6-a-summary-what-every-programmer-should-know-about-solid-state-drives/
>
> An interesting article. Anyone want to see if there are any modifications we should make to std.stdio to work better with SSDs? (Such as changing the buffer sizes.)


This article is not about "coding", but information about SSDs.

Considering spinning drives and SSDs separately means create two separate configurations for software. So you either:

1. Provide two separate code one is written for one configuration, and another
for SSD. This way the performance can be kept high,

2. Configurations can be changed on run-time, so there will be one executable only. But values won't be constant, so there is no compile time determination of values (buffer size etc.)


For most end user, 2nd is suitable.

Shouldn't system cache apply appropriate sync policy?

On 4/24/2015 2:18 AM, tcak wrote:
> On Friday, 24 April 2015 at 08:27:06 UTC, Walter Bright wrote:
>> http://codecapsule.com/2014/02/12/coding-for-ssds-part-6-a-summary-what-every-programmer-should-know-about-solid-state-drives/
>>
>>
>> An interesting article. Anyone want to see if there are any modifications we
>> should make to std.stdio to work better with SSDs? (Such as changing the
>> buffer sizes.)
>
>
> This article is not about "coding", but information about SSDs.

The section I linked to is definitely about coding for SSDs.


> Considering spinning drives and SSDs separately means create two separate
> configurations for software. So you either:
>
> 1. Provide two separate code one is written for one configuration, and another
> for SSD. This way the performance can be kept high,
>
> 2. Configurations can be changed on run-time, so there will be one executable
> only. But values won't be constant, so there is no compile time determination of
> values (buffer size etc.)
>
>
> For most end user, 2nd is suitable.

Things are configurable in std.stdio. But most people will just use the default settings. The default settings should be optimized for SSDs, not spinning drives.

On Friday, 24 April 2015 at 08:27:06 UTC, Walter Bright wrote:
> http://codecapsule.com/2014/02/12/coding-for-ssds-part-6-a-summary-what-every-programmer-should-know-about-solid-state-drives/
>
> An interesting article. Anyone want to see if there are any modifications we should make to std.stdio to work better with SSDs? (Such as changing the buffer sizes.)

This article seems to target operating system authors more than application programmers, as OS caches will invalidate most application-side changes.

The HN comments are also mostly dismissive of this article:
https://news.ycombinator.com/item?id=9431571

On Friday, 24 April 2015 at 19:35:08 UTC, Walter Bright wrote:
> Things are configurable in std.stdio. But most people will just use the default settings. The default settings should be optimized for SSDs, not spinning drives.

That would be unwise - as HDDs are much slower (and still much more common), optimizing for SSDs at the expense of HDD performance will cause overall performance to be much worse until HDDs become rare.

I mean, assuming that such optimizations aren't just theoretical.

On Fri, 24 Apr 2015 01:27:15 -0700, Walter Bright wrote:

> if there are any
> modifications we should make to std.stdio to work better with SSDs?
> (Such as changing the buffer sizes.)

yes: don't do anything. it's OS task to cope with that.

On Saturday, 25 April 2015 at 11:34:22 UTC, ketmar wrote:
> On Fri, 24 Apr 2015 01:27:15 -0700, Walter Bright wrote:
>
>> if there are any
>> modifications we should make to std.stdio to work better with SSDs?
>> (Such as changing the buffer sizes.)
>
> yes: don't do anything. it's OS task to cope with that.

well beyond the area I know, but it seems like given the relative structure of costs for random seeks for SSDs you often want to process files in parallel, whereas the opposite is true for spinning platters.  The OS can't help you here.

perhaps not for the standard library, but maybe it would be nice to have a function to detect whether a path is on an SSD or not.

I am not sure if there is a standard way to detect this.  There is a hacker way here:
https://stackoverflow.com/questions/908188/is-there-any-way-of-detecting-if-a-drive-is-a-ssd

and some others check the output of smartmontools.

But surely, it would be a start to make it easy for the user to know so she can shape her approach accordingly.

On Sat, 25 Apr 2015 14:19:30 +0000, Laeeth Isharc wrote:

> But surely, it would be a start to make it easy for the user to know so she can shape her approach accordingly.

i believe that this must be controlled with `version` or cli arg, and it belongs to application logic, not standard library.