forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

One Person's Frill Is Another's Essential feature ...

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Thu Mar 23, 2017 3:22 am    Post subject: One Person's Frill Is Another's Essential feature ... Reply with quote

It is indeed, as it is for example on this forum from time to time, but that's only healthy I think.

Here are some ore wise-words I came across this afternoon in an article I dropped on talking about the wheelings and dealings which evolved around the 'creation' of Fortran 90 :-

Quote:
"... which is why a committee ..." (or maybe indeed a group of users on a forum like here ? (my words) Smile ) "... simply cannot design something small and elegant"


... the people who said this obviously don't know that 'small and elegant' is usually mutually opposd to the concept of 'fast, complete and useful !

Quote:
"Fortran 77, let it not be forgotten (though often it is), was rather a spatchcock (1) affair, agreed because people agreed that they had to produce something even if they could not agree on what it should be."


Quote:
"Another tale going round was that free source form would invalidate 'millions of lines' of existing code. That these scares had no foundation did not matter: as the great Dr Goebbels taught us, such stories do gain credence among people who do not bother to check the facts. "


In hindsight this should of course have read ... "make millions of lines of code sometimes a pain in the ar-teries to convert" LOL

Quote:
"the sequence of Fortran 66, 77, 88 was appealing in itself."

indeed 11 years seems like a reasonable period, whereas90-77=13 is ... unlucky for some ? and 2003-1990=13 also oo-er now there's a
disturbing co-incicìdence if you're superstitious.
Unlucky for some Eh Dan, I wonder if this is this at the origin of the 'de-bugging devilry' you come across a lot ??? LOL

Want to read more ? (I recommend it ) .....

http://www.fortranplus.co.uk/app/download/23714308/brian_meeks_fortran_saga.pdf

Now, whatever happened to mainstream F 2003 and F 2008 ???
(maybe as alluded to in the quote above they should have been 99 (the 'missing' revision') ... 00 and 11 to have been even more appealing ???)

Notes

(1) spatch·cock
ˈspaCHˌkäk/

noun
1. a chicken or game bird split open and grilled.

verb:
spatchcock; 3rd person present: spatchcocks; past tense: spatchcocked; past participle: spatchcocked; gerund or present participle: spatchcocking

1. split open (a poultry or game bird) to prepare it for grilling.
Britishinformal

2. add (a phrase, sentence, clause, etc.) in a context where it is
inappropriate. "a new clause has been spatchcocked into the bill"

-------------------------------------------

... of course, you can see why F90 took so long since spatchcocking is not always as easy as it sounds as demonstrated here Wink ....

https://www.youtube.com/watch?v=Adfipy3lp9o
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Thu Mar 23, 2017 5:20 pm    Post subject: Reply with quote

John,

As to whether 'small and elegant' is usually mutually opposed to the concept of 'fast, complete and useful', I refer you to Colin Chapman (founder of Lotus cars) and his aphorism 'simplicate and add lightness', although as a long-time (but thankfully former) owner of several of those vehicles, I must say that he forgot to add 'fragile; expensive and often fatal to own'!

I would also refer you to a corollary of Godwin's Law, viz that anyone who resorts to an analogy with the Nazis has automatically lost whatever debate was in progress.

You are welcome to my copy of Metcalf & Reid's book 'Fortran 8X Explained', which is now a historical relic, if you are seriously into Fortran archaeology*. Many of the 'progressives' obviously disliked Fortran 77 intensely, and wanted to turn it into a simalcrum of Algol-60. Observing that you can't make a sow's ear into a silk purse and this conversion is of that sort - why should you want to? As a money bag, the pig leather would be far more durable (although granted, less decorative to show off); the effort to create a leather bag from a pig's ear far less than harvesting all those cocoons; it would be cheaper and it also would have the advantage of being edible at times of need! (Maybe not by everyone).

Sadly, 'pig's ear' is a metaphor for a mess, and maybe Fortran-77 is that too, but frankly I'm the sort of bloke who is happier with a utilitarian pigskin wallet than wielding a silk purse!

It was also interesting to read that the word 'module' was intended to have a different meaning to that which it is attached to now. In both cases it was a redefinition of the common usage at the time, meaning separately compiled block of code.

Eddie

* 'Effective Fortran 77' and 'Fortran Optimization' by Metcalf on his own could be added to the book offer: neither is particularly helpful ...
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Mar 24, 2017 12:08 am    Post subject: Reply with quote

One of the most frustrating phrases in the Fortran 77 (and more recent) standard is "processor dependent". It was an excuse to exclude many "industry accepted features" from being required. Once, and only once, I transferred a large F77 like program to a large IBM thing, only to be amazed at the features that weren't supported by the IBM Fortran 77. On closely reading the standard, many of these were described as "processor dependent", such as what errors can be trapped by an IOSTAT= and what should be the response.

For us dinosaurs, who have stalled at F95, it is difficult to understand what has been the approach for F03, F08 and now F15. I find the complexity of the new standards too much to contemplate and wonder what their new programming approaches are achieving. Certainly not what my work is requiring.

What have these committees created ?
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Mar 24, 2017 10:26 am    Post subject: Reply with quote

John,

If you are a dinosaur, then you must be a Cretaceous dinosaur whereas I am a Jurassic one, as I stalled pretty much at Fortran 77! Fortunately software has never been my main interest, just a tool.

Eddie

PS. Why does the default integer have to be 8 bytes in a 64-bit compiler? There appears to be some confusion between needs for addressing and the storage of integer numbers.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Mar 24, 2017 1:03 pm    Post subject: Reply with quote

Why does the default integer have to be 8 bytes in a 64-bit compiler?

There is a view that the default integer should be able to address the memory that is being used,
16 bit > integer*2
32 bit > integer*4
64 bit > integer*8

Fortran 95 (typically) uses 4-byte integer (*4) as default, which ignores the address targets.
Actually some/most would claim that Fortran 95 is supposed to be abstract from the practicality of memory size. Other recent discussions of the SIZE intrinsic demonstrate this conflict between the standard and what is practically required.
Should the value of KIND = the byte size is another conflict between the standard and the practical.
Many F95 + supporters would say I am wrong for being practical, although the F77 standard certainly had a foot in both camps.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Mar 24, 2017 2:23 pm    Post subject: Reply with quote

It was a rhetorical question, but a serious one nevertheless.

If a 64 bit integer can represent numbers up to 9,223,372,036,854,775,807 then what practical advantage is that over a 4 byte integer (2,147,483,647)? When was it necessary to distinguish exactly between 9,223,372,036,854,775,807 and (say) 9,223,372,036,854,775,806? Ordinarily, we need the precision of an integer (memory addressing aside) for small numbers. So, for example, if I get a bill of £100, then I am oblivious to the pennies, whereas if I am asked to pay for something with coins, when I try to carry less than £5 worth (it would be less except that the smallest note is a fiver) then I would count them exactly.

The view that the default integer should be the same as the addressable range of bytes is a reversion to Fortran-66 (Triassic, according to my dinosaurischian geological era classification analogy) practice. (i.e. default REAL, default INTEGER, default LOGICAL all the same size - if LOGICAL was even supported). I particularly dislike LOGICAL*anything, because it is so wasteful: 87.5% (counting 1 bit in 8) or 99.6% (if you count all the permutations) with even LOGICAL*1 and very quickly getting worse as one goes to *2, *4 etc).

As an engineer, John, you appreciate that INTEGER*1 is perfectly adequate to hold the number of coordinates per node (2 or 3), and the number of nodes per element (from 3 to say 20) - to use a finite element analysis context. Any more and it is simply wasteful.

In fact, it is difficult for me to see why there is such a thing as a default variable size at all: you can either specify it explicitly in your source code, or select it at compile time, and if, as the Fortran mammalia (i.e. devotees of 90 et seq.) would have us declare the type of every variable, we might as well go the whole hog and declare its size at he same time.

As for addressing all the memory available, then how come we used 16 bit MS Fortran under DOS with 1 Mb? Probably because the segmented architecture was effectively 20 bit addressing (segment & offset) before Mecej4 jumps in. As he pointed out elsewhere, this style is embedded in x64 as well, although as always, the terminology has changed.

Eddie
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sat Mar 25, 2017 1:54 am    Post subject: Reply with quote

Eddie,

I have only a few 64-bit programs in use. They still mostly use INTEGER*4, except for the INTEGER*8 subscripts of the very few large arrays I am using.
This does create problems for getting the correct kind for subroutine arguments; an old problem which is now becoming a more frequent issue.
Mixing of *2, *4 and *8 integers is becoming a bit messy, although I have not yet resorted to generic interfaces.

The other area which I have not completely resolved is disk I/O of these large arrays, as my disk record formats are typically limited to 2gb. FTN95 sequential binary format has an interesting approach for identifying longer records, which I could adapt.

Re LOGICAL arrays, our old ideas of using the smallest kind variable to save memory, is probably less of an issue, now that 32 gb is my typical memory. An array(1000,3) changing from I*4 to I*8 really does not have any impact, when the main array is 15gb.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Sat Mar 25, 2017 2:12 pm    Post subject: Reply with quote

I just have an aversion to wastefulness, not that there isn't space in which to be wasteful.

For your disk I/O, do invest in an SSD for your scratch files (if that terminology isn't obsolete).

Eddie
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sun Mar 26, 2017 3:37 am    Post subject: Reply with quote

LitusSaxonicum wrote:
For your disk I/O, do invest in an SSD for your scratch files (if that terminology isn't obsolete).

That terminology is still relevant and I do use a C:SSD. However, with 32gb installed memory and Win 7+, the OS disk buffering appears to do a similar thing, especially if the large "scratch" files are being generated in the same run. With CLOSE (UNIT=lu, STATUS='DELETE'), they might never get to the disk.
With all the changes of a 64-bit OS, running a 32-bit program with scratch I/O can be nearly as fast as the 64-bit version.
However, writing new code that doesn't require scratch files is a lot quicker to develop. I have also been re-writing some of my FE solutions removing the memory partitioning, allowing for better solution approaches that suit multi-threading. My shifted subspace eigen-solver is now orders of magnitude faster, although speeding up old approaches from 80's sometimes doesn't compete with the diverse options in modern commercial packages.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue Mar 28, 2017 9:13 pm    Post subject: Reply with quote

is that all an SSD is then .... a quick hard drive ?
I assume internally they're just like strung together pendrive memory ? (just like computer batteries are serially comnected bog-standard rechargeable AAA's ) ?
SSD's still seem a bit expensive to me
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Mar 29, 2017 2:09 pm    Post subject: Reply with quote

SSD s are more complicated issues than they were when they were introduced, because they are several different technologies. eMMC seems to be strung together pendrive technology (low end) whereas the PCI versions are probably more like RAM, but there is a controller board to make the memory look like a hard drive. As far as the Fortran programmer is concerned, they are fast hard drives.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Mar 30, 2017 5:07 am    Post subject: Reply with quote

If you are not an extremist in computing you will not notice any serious speedup worth of spent money if switch on SSD vs fast harddrives like WD Black or WD Gold. Fast Windows boot with SSD is an urban legend, few seconds faster out of 20 seconds is a joke. And eventually when you install more and more programs your computer will be as slow as it always was with Windows.

So I use fast SSD with good lifetime only for Windows pagefile and do that with some pain, I am not sure yet if SSDs rewrite capacity is like manufacturers claim. They always lied about MTBF ~2 million hours with harddrives while they lasted barely one-two years working 12-15 hours each day till I switched to WD Black 5 years back

Samsung Pro series are really fast, specifically lately with PCI express ones with more then 3GB/second speeds , do not look at anything else
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Mar 30, 2017 7:40 am    Post subject: Reply with quote

The benefits of an SSD drive are difficult to assess.
To speed up your system, you can either change a HDD for an SSD or install more memory, so that you don't need frequent disk access. Memory disk cache is a good substitute for faster disks.
That is for scratch files, however if you are reading a lot of information from existing files on the disk, then SSD should be a definite advantage.
Early SSD performance was a bit of a problem, although there is now a newer M.2 slot interface with much faster transfer rates. Recent posts on this forum did show that with SSD performance, the bottleneck shifts to the software converting text to numbers, so depending on what information is in the file, the data conversions can be critical.

SSD are not expensive, especially if you are comparing against the alternative of more installed memory. A 250 or 500 gb SSD should not cost too much. I have a recent pc quote for a Samsumg 500gb 750 EVO SSD for $AU200 vs WD Black 1TB HDD for $AU100 vs G.Skill 4 blue 32 gb memory for $AU 300, all of which I was planning to install in my next pc.

As with the title of this thread, all 3 are essential features. ( my recent estimate of performance !!)

John
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Thu Mar 30, 2017 12:19 pm    Post subject: Reply with quote

The real cost of any hard drive of any technology occurs not when you buy it, but in your time doing periodic backups and restoring information when the drive eventually fails. Some are incredibly long lived, and others prove fragile, and while some models and brands have better records statistically, you cannot guarantee any individual drive.

As for Windows startup, my eMMC-equipped tablet is like lightning on startup. I had a laptop that I thought was fast, but it is possible to cheat by going into hibernation (or part hibernation) when shutdown is selected. This is quite separate from choosing 'sleep'.

In any case, the wait for startup is a negligible part of the day's work.

Eddie
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group