Then vs Now Programming WAS: Re: AMD vs Intel memory managemement

Sat Jun 15 09:29:17 MST 2013

I just saw this 

http://promotions.newegg.com/NEemail/June-0-2013/Weekend15/index-landing.html?nm_mc=EMC-EXPRESS061513&cm_mmc=EMC-EXPRESS061513-_-EMC-061513-Index-_-E0A-_-EditorsElite

Your Price: $109.99

In 1998 I worked for an HMO that employed about 650 people.  If I remember correctly we had about 4GB of HD storage.  My unit got 500MB.

Today I have more storage and possibly more computer horsepower in my little home office just for PHP Programming.

In the old days you needed to optimize for the machine because computers where very expensive, while labor in comparison was less expensive.

Today the top programmers are being well compensated.  For a couple thousand you can build a very powerful computer that can do anything a $100,000/yr plus programmer would ever need.  

So now we optimize for labor.  Labor is now where the real cost is.

In 1988 I was an intern with the city of Tucson.  I was told the mainframe cost one million dollars.  It was connected to hundreds of dumb terminals.

Today I might have more power in my home office at the cost of under $2000.  And my computers are not water cooled like that mainframe.  

It is a business decision.

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

Keith Smith

--- On Fri, 6/14/13, Kevin Brown <kevinbrownbdc at gmail.com> wrote:

From: Kevin Brown <kevinbrownbdc at gmail.com>
Subject: Re: Then vs Now Programming WAS: Re: AMD vs Intel memory managemement
To: plug-discuss at lists.phxlinux.org
Date: Friday, June 14, 2013, 11:00 PM

  "Anyone can cook. But not everyone can become a great chef."

As more and more people have gained access to the tools, the level of 
proficiency to use said tools has dropped. One example from this thread.

"Linux used to be rock stable, now it crashes every three months"

More people are trying to make it work with more and disparate hardware. 
That makes it harder and harder for a coder to really optimize the 
performance of any given amount of code. So that optimization comes in 
later... at the compiler generally. This is why Intel spends so much on 
their compiler and performance gains are seen just from changing 
compilers. But that optimization comes at a price. It won't work as well 
on AMD processors. It can't be used at all on Sparc, Power, etc...

The real bloat comes when you find out things like a microsoft developer 
crammed a limited version of their Flight Simulator into Excel... and 
that inclusion made it to release. Or the different ways you access 
functions aren't the same code in the backend... which means they were 
probably made by different developers at different times under different 
conditions. So now you have multiple, similar yet different, copies of a 
function in the compiled code. Same thing with Linux and all the 
different libraries and GUIs and other applications...

> John carmack has similar rants and epiphanies on his twitter feed.
>
> On Friday, June 14, 2013, Dazed_75 wrote:
>
>     Nevertheless, as one of those old-timers, I have to be concerned
>     at the apparent total disregard for code efficiency.  Far too many
>     of the tools to make design and development efficient do so with
>     inexcusably crappy code in the tools themselves.
>
>     The tools still need to be at least cognizant of efficiency or
>     they will produce exponentially inefficient code.  That is a
>     complete and total waste of resources.  If I am rich, it does not
>     follow that I should be ignorant and throw stacks of money into
>     the wind lest I become not rich.  On the other hand, spending my
>     riches wisely can make me a better businessman and able to be a
>     better human being while retaining the richness to continue doing so.
>
>     So don't ignore efficient code as a waste of money, but choose
>     wisely when to be spendthrift and when to be profligate.
>
>
>
>     On Fri, Jun 14, 2013 at 9:33 AM, Paul Mooring <paul at opscode.com>
>     wrote:
>
>         I think as an extension of this thought, there's still plenty
>         of systems programs writing really "tight" code.  The linux
>         kernel for example is pretty efficient, in my opinion it's on
>         par with ye programmers of old.  The difference now a days
>         there's a *lot* more programmers and the field is much easier
>         to get in to.
>
>         Paul Mooring
>         Operations Engineer
>         www.opscode.com <http://www.opscode.com>
>
>         ------------------------------------------------------------------------
>         *From:* plug-discuss-bounces at lists.phxlinux.org on behalf of
>         Kevin Fries
>         *Sent:* Thursday, June 13, 2013 6:43 PM
>
>         *To:* Main PLUG discussion list
>         *Subject:* RE: Then vs Now Programming WAS: Re: AMD vs Intel
>         memory managemement
>
>         I think there is a big reality being missed here.  Back in the
>         "old days" when developers wrote "tight" code, that was out of
>         necessity not out of some higher purpose.  Computers did not
>         do much, spell checkers were a luxury, as were point and click
>         interfaces.  I remember spending more money for my first 10MB
>         hard drive than i would spend for a 1TB today.  The price to
>         write this tight code today is too high for the benefit it
>         would bring.  Yes code is more bloated today, but if you take
>         a look at the bloat in proportion to the increase in memory,
>         disk, and network speed, it could be argued that software has
>         gotten smaller, not larger.
>
>         Just my $0.02
>
>         Kevin
>
>         On Jun 13, 2013 2:03 PM, "Carruth, Rusty"
>         <Rusty.Carruth at smartstoragesys.com> wrote:
>
>             IMHO, the answer is yes.  And the answer is no.
>
>             Operating systems in ‘the olde days’ were REALLY small,
>             and didn’t do much. No gui, for one! (Well, ok, on the IBM
>             1130 I used the GUI was the flashing lights on the console!)
>
>
>             Shoot, the entire boot loader fit on a single 80 column
>             punch card.  The card had I think 12 bit positions per
>             column, so that means we could load a program (from
>             cards!) with 120 bytes of program. The computer ran 16 bit
>             instructions, so that means in 60 instructions we could
>             read binary data from the card reader (12 bits at a time),
>             and store it into memory!
>
>             FORTRAN (and later C) and assembly language were probably
>             the primary languages in use for applications.
>
>             As James said: “Cache?  We don’t need no stinkin’cache!” 
>             Cache was a luxury that Idon’t think we even considered…
>
>             I’m not sure how much is language bloat, and how much is
>             (perceived?) lack of need to be careful abo
>
>     -- 
>     Dazed_75 a.k.a. Larry
>
>     Please protect my address like I protect yours. When sending
>     messages to multiple recipients, use the BCC: (Blind carbon copy).
>     Remove addresses from a forwarded message body before clicking Send.
>
>
>
> -- 
> A mouse trap, placed on top of your alarm clock, will prevent you from 
> rolling over and going back to sleep after you hit the snooze button.
>
> Stephen
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss

---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20130615/56fa00b2/attachment.html>