Coding for solid state drives

[ketmar via Digitalmars-d]

On Sat, 25 Apr 2015 16:40:51 +0000, Laeeth Isharc wrote:

> On Saturday, 25 April 2015 at 16:10:11 UTC, ketmar wrote:
>> 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.
> 
> 
> I defer to your greater expertise.
> 
> But I should have thought that if csv parsing belongs in a standard
> library (something that is easy for a user to write himself) then
> detecting whether a path is on an SSD might perhaps too.  (Bearing in
> mind it's more of a system thing not so easy for every user to write
> himself in a platform independent way).

and now something more serious: trying to detect what storage propgram 
using is completely unreliable. you can't optimise for all cases, and you 
can't even detect all cases. big raid which can be faster than SSD with 
"SSD pattern"? ah, ok, nobody cares, we detected it as HDD. virtual 
drive, which can be anything at all? fuse mount point? i can think out 
alot of that.

that's why operational mode should be controlled by cli switch. if user 
*really* cares about performance, he *will* know what HW he has and how 
to make program fully utilize it. and in other cases let OS i/o scheduler 
do it work without trying to needlessly "help" it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150426/635d300d/attachment.sig>