gnuastro-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gnuastro-commits] master abcc408 5/7: Removed argument on speed in para


From: Mohammad Akhlaghi
Subject: [gnuastro-commits] master abcc408 5/7: Removed argument on speed in parallel-build-in-tmpfs
Date: Thu, 4 Aug 2016 23:21:06 +0000 (UTC)

branch: master
commit abcc40875896d092f7a24863f453cd6b621fcbdd
Author: Mohammad Akhlaghi <address@hidden>
Commit: Mohammad Akhlaghi <address@hidden>

    Removed argument on speed in parallel-build-in-tmpfs
    
    Following some tests suggested by Mosè (in task #14100), we realized that
    some bottle-neck is stopping the speed increase that we initially expected
    from configuring and building in the RAM. So the speed argument is
    currently removed from the explanations. Maybe later, if we find the
    bottleneck, we can explain the reason so others are not as confused as we
    were ;-)!
    
    Still I believe the two advantages listed (having a clean source file and
    not forcing two many read/writes on the HDDs and/or SSDs) are worth it to
    keep the script for more testing.
---
 parallel-build-in-tmpfs |   20 +++++++++-----------
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/parallel-build-in-tmpfs b/parallel-build-in-tmpfs
index 08935f9..f7dec41 100755
--- a/parallel-build-in-tmpfs
+++ b/parallel-build-in-tmpfs
@@ -4,15 +4,14 @@
 # temporary tmpfs directory in the RAM. Then it will create a symbolic link
 # to access that temporary directory called 'build'.
 #
+# MOTIVATION:
+#
 # The configure and build process involves the creation, reading, and
 # modification of a large number of files (input/output, or I/O). Therefore
 # I/O issues can directly affect the work of developers who need to
 # configure and build Gnuastro numerous times. Some such issues are listed
 # below:
 #
-#   - I/O can be slow in non-volatile (non-RAM) memory like traditional
-#     hard disks (HDDs) and even SSDs.
-#
 #   - I/O will cause wear and tear on both the HDDs (mechanical failures)
 #     and SSDs (decreasing the lifetime).
 #
@@ -24,13 +23,12 @@
 #
 # One solution to these problems is the tmpfs file system (see
 # https://en.wikipedia.org/wiki/Tmpfs). Any file in tmpfs is actually
-# stored in the RAM (and possibly SAWP), not on HDDs or SSDs. Therefore I/O
-# can be much faster and will also not harm the non-volatile memory
-# hardware. However, due to the volatile nature of RAM, files in the tmpfs
-# filesystem will be permanently lost after a power-off, since they are all
-# derivative files (not files that have been directly manipulated) there is
-# no problem in this and this feature can be considered and automatic
-# cleanup.
+# stored in the RAM (and possibly SAWP), not on HDDs or SSDs. Therefore the
+# large number of small file I/O will not harm the HDDs or SSDs. However,
+# due to the volatile nature of RAM, files in the tmpfs filesystem will be
+# permanently lost after a power-off, since they are all derivative files
+# (not files that have been directly manipulated) there is no problem in
+# this and this feature can be considered and automatic cleanup.
 #
 # The modern GNU C library (and thus the Linux kernel) define the
 # '/dev/shm' directory for this purpose (POSIX shared memory). Therefore
@@ -57,7 +55,7 @@
 #
 # Original author: Mohammad Akhlaghi <address@hidden>
 # Contributing author(s):
-#
+#   Mosè Giordano <address@hidden>
 # Copyright (C) 2016, Free Software Foundation, Inc.
 #
 # Gnuastro is free software: you can redistribute it and/or modify it under



reply via email to

[Prev in Thread] Current Thread [Next in Thread]