Quantcast

Maximum PC

It is currently Sat Dec 20, 2014 11:21 pm

All times are UTC - 8 hours




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: Fat apps
PostPosted: Sun Jul 08, 2012 10:06 am 
8086
8086

Joined: Sun Jul 08, 2012 9:59 am
Posts: 1
I know we have tones of memory and stuff, but does anybody care to write efficiently anymore. Network connections can be just as valuable as memory or mips. It has gotten horrible if I try to tether. Yahoo is the worst.


Top
  Profile  
 
 Post subject: Re: Fat apps
PostPosted: Tue Jul 10, 2012 8:59 am 
Smithfield
Smithfield

Joined: Sun Jun 18, 2006 7:37 pm
Posts: 5533
Write what efficiently?


Top
  Profile  
 
 Post subject: Re: Fat apps
PostPosted: Tue Jul 10, 2012 7:06 pm 
Million Club - 5 Plus
Million Club - 5 Plus
User avatar

Joined: Sat Jul 08, 2006 6:23 am
Posts: 2647
Location: Folding as BlackSun59
LatiosXT wrote:
Write what efficiently?

Programs. Compared to the olden days, many of today's apps are true fatware.
Back when computers had small amounts of RAM, programmers had to cram a lot of code into a small footprint.
For example, I used to write TI-BASIC code for TI 99/4A computers. With only 16Kilobytes of RAM to work with, you learn early on to write with economy in mind.


Top
  Profile  
 
 Post subject: Re: Fat apps
PostPosted: Tue Jul 10, 2012 7:21 pm 
Smithfield
Smithfield

Joined: Sun Jun 18, 2006 7:37 pm
Posts: 5533
OvenMaster wrote:
LatiosXT wrote:
Write what efficiently?

Programs. Compared to the olden days, many of today's apps are true fatware.
Back when computers had small amounts of RAM, programmers had to cram a lot of code into a small footprint.
For example, I used to write TI-BASIC code for TI 99/4A computers. With only 16Kilobytes of RAM to work with, you learn early on to write with economy in mind.

If you want the conveniences of high level languages, you have to trade performance and resource requirements. Otherwise, we might as well be writing in assembly to get the most bang for the buck. But anyway, today we have gigabytes of memory readily available, why not use it?

Also 16KB of RAM? Pfft. Try 512 bytes. Running something RTOS like.


Top
  Profile  
 
 Post subject: Re: Fat apps
PostPosted: Wed Jul 18, 2012 7:25 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
OvenMaster wrote:
LatiosXT wrote:
Write what efficiently?

Programs. Compared to the olden days, many of today's apps are true fatware.
Personally, I think there is a grain of truth in what you're saying. In addition to a fairly substantial academic background, I have about six years of commercial industry experience. There has probably been two dozen occasions when I've come across some legacy code that I could improve substantially. Unfortunately, managers will very seldom give you the go ahead to fix existing code. It makes them look bad (ie why didn't your team get it right the first time we paid for it). To be fair, a lot of buggy, slow code was written over twenty years ago.

I believe the primary reason for 'fatware' becoming more prevalent is the number/variety of users. The combination of less sophisticated users and the desire to have 'software suites' that perform multiple tasks for the user is the primary force increasing the size of applications. This has been an enduring theme in the classic Vi/Emacs war. Even when I was a dedicated Vim user, it was pretty clear (to me at least) that Emacs had won the war.

OvenMaster wrote:
Back when computers had small amounts of RAM, programmers had to cram a lot of code into a small footprint. For example, I used to write TI-BASIC code for TI 99/4A computers. With only 16Kilobytes of RAM to work with, you learn early on to write with economy in mind.
I love hearing about older software development experiences. What kind/types of applications were you writing? BTW, BASIC isn't exactly the most efficient language; The same application written in FORTRAN would probably be smaller and significantly faster.


Top
  Profile  
 
 Post subject: Re: Fat apps
PostPosted: Wed Jul 18, 2012 7:50 pm 
Smithfield
Smithfield

Joined: Sun Jun 18, 2006 7:37 pm
Posts: 5533
While we could blame legacy code for causing bloating, some software released in the past 5 years or so, like Chrome, will gladly eat your RAM. I think the last time I was using it (I stopped using it ever since about the start of the year), I could have somewhere between 50-100MB per tab. And for websites that don't appear to be resource heavy.

Unless Chrome was forced to use some inefficient web standard for that page.

Plus some coding habits I found can lead to some extra bits of code. For instance, when I'm writing something to control an LED, I have an explicit "LED_On" and "LED_Off" function, rather than "LED_State(bool Enable)". Or in my last work project, Red_LED_On(), Green_LED_On(), etc. Sure, I could probably save a few lines of code by having some LED_On(uint8_t Color, uint8_t Enable) function. But I also just like reading something that's clear.

Another edit:
I also want to note that back then, since memory was precious, anything that had to deal with multi-media had either a lot of memory (For the time), or it had to procedurally generate it. I think procedural generation is kind of going the wayside because... well we have memory.


Top
  Profile  
 
 Post subject: Re: Fat apps
PostPosted: Thu Jul 19, 2012 7:32 pm 
Million Club - 5 Plus
Million Club - 5 Plus
User avatar

Joined: Sat Jul 08, 2006 6:23 am
Posts: 2647
Location: Folding as BlackSun59
Gadget wrote:
I love hearing about older software development experiences. What kind/types of applications were you writing? BTW, BASIC isn't exactly the most efficient language; The same application written in FORTRAN would probably be smaller and significantly faster.

I wrote a few simple games; one was a gangster FPS with fairly decent graphics and sound. Another was a crude business tycoon sim. One program was (believe it or not) a piano tuning utility that I'd tested against tuning forks. No way did I just get a table of frequencies for a piano and plug the data in... no, I developed do-loop routines with lots of trial and error to generate and fill a big array with the proper frequencies to within 0.001% accuracy.

I'd used TI-BASIC because assembly required some quite expensive add-ons... I don't remember if it was a cartridge or peripheral, but I do remember it was expensive. I wrote everything so that all a person needed was the TI console, a cassette player/recorder, and a TV set with sound. Did I sell anything? Yup, mostly to grade schools, via magazine ads.

As far as FORTRAN goes, that's what I'd originally learned to code with a year earlier at University of New Brunswick. We used punchcards and a monstrous IBM mainframe. We were limited to 30KB. :lol:


Top
  Profile  
 
 Post subject: Re: Fat apps
PostPosted: Sun Jul 29, 2012 2:13 am 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
LatiosXT wrote:
Plus some coding habits I found can lead to some extra bits of code. For instance, when I'm writing something to control an LED, I have an explicit "LED_On" and "LED_Off" function, rather than "LED_State(bool Enable)".
Putting the software engineering aspects aside (but I tend to agree that LED_On and LED_Off are clearer and less error prone), I would have thought that the difference in memory consumption would be negligible. Did you do some testing that confirmed a difference? If so, what was the cause?

LatiosXT wrote:
While we could blame legacy code for causing bloating, some software released in the past 5 years or so, like Chrome, will gladly eat your RAM. I think the last time I was using it (I stopped using it ever since about the start of the year), I could have somewhere between 50-100MB per tab. And for websites that don't appear to be resource heavy.

Not that I wish to become the defender of Chrome, but I have about twenty tabs open currently and the largest is 25MB with most somewhere in the 6MB to 10MB range. The only time that I've ever really had trouble with Chrome is when a page has (what I assume) are badly written flash applications (as killing the Shockwave Flash plugin has always cleared up the problem).


Top
  Profile  
 
 Post subject: Re: Fat apps
PostPosted: Sun Jul 29, 2012 2:40 am 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
OvenMaster wrote:
As far as FORTRAN goes, that's what I'd originally learned to code with a year earlier at University of New Brunswick. We used punchcards and a monstrous IBM mainframe. We were limited to 30KB. :lol:

LOL ... 30KB? Talk about being spoiled. =)


Top
  Profile  
 
 Post subject: Re: Fat apps
PostPosted: Sun Oct 21, 2012 9:21 pm 
Smithfield
Smithfield

Joined: Sun Jun 18, 2006 7:37 pm
Posts: 5533
Gadget wrote:
LatiosXT wrote:
Plus some coding habits I found can lead to some extra bits of code. For instance, when I'm writing something to control an LED, I have an explicit "LED_On" and "LED_Off" function, rather than "LED_State(bool Enable)".
Putting the software engineering aspects aside (but I tend to agree that LED_On and LED_Off are clearer and less error prone), I would have thought that the difference in memory consumption would be negligible. Did you do some testing that confirmed a difference? If so, what was the cause?

I haven't done any explicit research on it, but I doubt there's any real impact on something simple like this. Given my experience with the MSP430 I used, which is probably how RISC works in general, I could see a single function looks like this when compiled:

Code:
LED_State
MOV LED_GPIO, R0  ;assuming R0 holds the state that's passed through
RET


Versus this
Code:
LED_On
  MOV LED_GPIO, 1
  RET

LED Off
  MOV LED_GPIO, 0
  RET

So you're doubling the code space from two instructions to four. This also consumes no memory anyway since the value is either in a register or is immediate.

For something more complex, say a periph_setup function versus a periph_init and a periph_deinit function, there wouldn't be much impact I would think. But it really depends on what the complimenting functions are trying to do.


Top
  Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 4 guests


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 post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

© 2014 Future US, Inc. All rights reserved.