Welcome, Guest. Please login or register.

Author Topic: Which way do you prefer or "Have it your way."  (Read 12924 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline stefcep2

  • Hero Member
  • *****
  • Join Date: Sep 2007
  • Posts: 1467
    • Show all replies
Re: Which way do you prefer or "Have it your way."
« on: May 15, 2013, 01:42:16 PM »
Quote from: rabindranath72;735028
My point was that software has not evolved as fast (and well) as hardware. If I have to write a letter or document, I don't need a word processor which occupies 300Mb ram.



One thing to consider is that as you go from 16 bit to 32 bit to 64 bit software, the smallest that any information can be is 16 bit, 32 bit and 64 bit respectively.  Even if you optimized it 100% the same software will always end up needing more ram and the executable will always be larger as you up the bits.

But I agree there is a lot of bloat, but no all is due to inefficient code  Some of it is due to feature creep: adding more and more features which are less and less useful.

Its interesting that this also extends to even things like icons: do we really need 32 bit photo-realistic icons that take up more ram, more cpu cycles?  I actually enjoy using Macos 7 for its simplicity.   I also now have a 8 color Workbench with the stock Commodore  icons.

And do we need animations of a page curling and turning when reading a document?  Well actually Apple seems to now think the answer is "no", with Jon Ives heavily involved in the new Mac interface design, and he is dead against "photo-realism".
 

Offline stefcep2

  • Hero Member
  • *****
  • Join Date: Sep 2007
  • Posts: 1467
    • Show all replies
Re: Which way do you prefer or "Have it your way."
« Reply #1 on: May 16, 2013, 01:32:37 AM »
Quote from: commodorejohn;735108


That's not true at all. Modern processors are perfectly capable of handling things at the byte level, and some architectures even support bit-field instructions. Some architectures do have a fixed instruction size, so code size can't always be reduced by much, but bloating of RAM usage for data is purely down to programmer laziness.




Really?  I did not know that.  Every 64 bit executable I've seen has been larger than its 32 bit counterpart and ALWAYS used more RAM.