a problem about memory - Unix

This is a discussion on a problem about memory - Unix ; Hi everyone, Sorry, I am a new fish here and my english is not good! I found a problem about memory. In a function I malloced more memory than beforethat is 4.5625Kb in theory. Then I watched the memory size ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: a problem about memory

  1. a problem about memory

    Hi everyone,

    Sorry, I am a new fish here and my english is not good!

    I found a problem about memory. In a function I malloced more memory
    than beforethat is 4.5625Kb in theory. Then I watched the memory size
    of the function process in Linux and Unix through the command of "ps".
    After comparing with the early memory size of the function which didn't
    have change, I found the increaseded size was different! In Linux and Unix
    the size is about 4Kb, but in windows the size watched from task manager
    is far more than 4Kb.

    can anyone help me and explain the phenomenon,please?

    Thanks in advance!


  2. Re: a problem about memory

    In article , "richi"
    wrote:

    > Hi everyone,
    >
    > Sorry, I am a new fish here and my english is not good!
    >
    > I found a problem about memory. In a function I malloced more memory
    > than beforethat is 4.5625Kb in theory. Then I watched the memory size
    > of the function process in Linux and Unix through the command of "ps".
    > After comparing with the early memory size of the function which didn't
    > have change, I found the increaseded size was different! In Linux and Unix
    > the size is about 4Kb, but in windows the size watched from task manager
    > is far more than 4Kb.
    >
    > can anyone help me and explain the phenomenon,please?
    >
    > Thanks in advance!


    When a process starts up it gets a data segment allocated for it, and
    malloc() uses this segment. Malloc() only needs to increase the size of
    the data segment if you ask for more memory than is available. In your
    case, there must already have been 4.5 KB available, so it didn't need
    to grow the process.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: a problem about memory


    "Barry Margolin" wrote in message
    news:barmar-C36649.15252125092008@news.motzarella.org...
    > In article , "richi"
    > wrote:
    >
    >> Hi everyone,
    >>
    >> Sorry, I am a new fish here and my english is not good!
    >>
    >> I found a problem about memory. In a function I malloced more memory
    >> than beforethat is 4.5625Kb in theory. Then I watched the memory size
    >> of the function process in Linux and Unix through the command of "ps".
    >> After comparing with the early memory size of the function which didn't
    >> have change, I found the increaseded size was different! In Linux and
    >> Unix
    >> the size is about 4Kb, but in windows the size watched from task manager
    >> is far more than 4Kb.
    >>
    >> can anyone help me and explain the phenomenon,please?
    >>
    >> Thanks in advance!

    >
    > When a process starts up it gets a data segment allocated for it, and
    > malloc() uses this segment. Malloc() only needs to increase the size of
    > the data segment if you ask for more memory than is available. In your
    > case, there must already have been 4.5 KB available, so it didn't need
    > to grow the process.


    I had added several pointer variable in a function, the memory size that
    the variable point to is 4.5625Kb in theory. Then I ran the programme in
    Unix, Linux and Windows. Watched the process info, I found the the increased
    memory size in Unix was the same in Linux. But it was different from the
    size in Windows, the size in Windows was more than size in Unix and Linux.
    The increased size in Unix and Linux was 4KB, and the increased size in
    Windows was not constant. it was 8KB, 12KB, 16KB or 20KB.

    Why this case happened?
    I think that the increased memory size shoud be the same in the several
    operating system. Could you explain the phenomenon for me?

    Thank you very much!


  4. Re: a problem about memory

    richi wrote:
    >
    > "Barry Margolin" wrote in message
    > news:barmar-C36649.15252125092008@news.motzarella.org...
    >> In article , "richi"
    >> wrote:
    >>
    >>> Hi everyone,
    >>>
    >>> Sorry, I am a new fish here and my english is not good!
    >>>
    >>> I found a problem about memory. In a function I malloced more memory
    >>> than beforethat is 4.5625Kb in theory. Then I watched the memory size
    >>> of the function process in Linux and Unix through the command of "ps".
    >>> After comparing with the early memory size of the function which didn't
    >>> have change, I found the increaseded size was different! In Linux and
    >>> Unix
    >>> the size is about 4Kb, but in windows the size watched from task manager
    >>> is far more than 4Kb.
    >>>
    >>> can anyone help me and explain the phenomenon,please?
    >>>
    >>> Thanks in advance!

    >>
    >> When a process starts up it gets a data segment allocated for it, and
    >> malloc() uses this segment. Malloc() only needs to increase the size of
    >> the data segment if you ask for more memory than is available. In your
    >> case, there must already have been 4.5 KB available, so it didn't need
    >> to grow the process.

    >
    > I had added several pointer variable in a function, the memory size that
    > the variable point to is 4.5625Kb in theory. Then I ran the programme in
    > Unix, Linux and Windows. Watched the process info, I found the the
    > increased
    > memory size in Unix was the same in Linux. But it was different from the
    > size in Windows, the size in Windows was more than size in Unix and Linux.
    > The increased size in Unix and Linux was 4KB, and the increased size in
    > Windows was not constant. it was 8KB, 12KB, 16KB or 20KB.
    >
    > Why this case happened?


    Because different platforms use different allocation schemes. Try a
    windows group if you want to know more about that platform's behaviour.

    --
    Ian Collins.

  5. Re: a problem about memory

    In article , "richi"
    wrote:

    > I had added several pointer variable in a function, the memory size that
    > the variable point to is 4.5625Kb in theory. Then I ran the programme in


    4.5625 KB? Are you really measuring the size down to a half a byte?

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  6. Re: a problem about memory

    Barry Margolin wrote:
    > In article , "richi"
    > wrote:
    >
    >> I had added several pointer variable in a function, the memory size that
    >> the variable point to is 4.5625Kb in theory. Then I ran the programme in

    >
    > 4.5625 KB? Are you really measuring the size down to a half a byte?
    >

    4.5625 * 1024 = 4672 bytes.

    --
    Ian Collins.

  7. Re: a problem about memory

    On 27 Sep, 04:05, Ian Collins wrote:
    > Barry Margolin wrote:
    > > In article , "richi"
    > > wrote:

    >
    > >> I had added several pointer variable in a function, the memory size that
    > >> the variable point to is 4.5625Kb in theory. Then *I ran the programme in

    >
    > > 4.5625 KB? *Are you really measuring the size down to a half a byte?

    >
    > 4.5625 * 1024 = 4672 bytes.



    I think the current nomenclature is:
    4.5625Kb == 4562.5 bits
    4.5625KB == 4562.5 bytes
    4.5625KiB == 4672 bytes

    Things would be so much more clear if we just
    dropped the greek prefixes and switched to base 7.

  8. Re: a problem about memory

    William Pursell wrote:

    > I think the current nomenclature is:
    > 4.5625Kb == 4562.5 bits
    > 4.5625KB == 4562.5 bytes
    > 4.5625KiB == 4672 bytes


    No, it's

    4.5625kb == 4562.5 bits
    4.5625kB == 4562.5 bytes
    4.5625KiB == 4672 bytes

    AFAIK there is no formal standard for the uppercase K prefix.
    Historically K was chosen to mean 1024 in order to distinguish
    it from k which meant 1000. So I think most people would still
    take K to mean 1024.

    --
    Geoff Clare

  9. Re: a problem about memory

    Geoff Clare wrote:
    > William Pursell wrote:
    >
    >> I think the current nomenclature is:
    >> 4.5625Kb == 4562.5 bits
    >> 4.5625KB == 4562.5 bytes
    >> 4.5625KiB == 4672 bytes

    >
    > No, it's
    >
    > 4.5625kb == 4562.5 bits
    > 4.5625kB == 4562.5 bytes
    > 4.5625KiB == 4672 bytes
    >
    > AFAIK there is no formal standard for the uppercase K prefix.
    > Historically K was chosen to mean 1024 in order to distinguish
    > it from k which meant 1000. So I think most people would still
    > take K to mean 1024.
    >

    When I was at school, I was taught that capitals (Kbits, MB, etc.)
    represented multipliers of 10 to a positive integer power, whereas lower
    case letters (mVolt, etc.) represented multipliers of 10 to a negative
    integer power. So, for example, M is mega and m is milli. In this schma,
    kilo is a capital K.

    This is surely standardised somewhere!

    Robert

  10. Re: a problem about memory

    Robert Harris writes:
    > Geoff Clare wrote:
    >> William Pursell wrote:
    >>
    >>> I think the current nomenclature is:
    >>> 4.5625Kb == 4562.5 bits
    >>> 4.5625KB == 4562.5 bytes
    >>> 4.5625KiB == 4672 bytes

    >>
    >> No, it's
    >>
    >> 4.5625kb == 4562.5 bits
    >> 4.5625kB == 4562.5 bytes
    >> 4.5625KiB == 4672 bytes
    >>
    >> AFAIK there is no formal standard for the uppercase K prefix.
    >> Historically K was chosen to mean 1024 in order to distinguish
    >> it from k which meant 1000. So I think most people would still
    >> take K to mean 1024.
    >>

    > When I was at school, I was taught that capitals (Kbits, MB, etc.)
    > represented multipliers of 10 to a positive integer power, whereas lower
    > case letters (mVolt, etc.) represented multipliers of 10 to a negative
    > integer power. So, for example, M is mega and m is milli. In this schma,
    > kilo is a capital K.


    The usual abbreviation for kilometer is km and for kilogram, it is
    kg.

  11. Re: a problem about memory

    * Robert Harris
    | When I was at school, I was taught that capitals (Kbits, MB, etc.)
    | represented multipliers of 10 to a positive integer power, whereas
    | lower case letters (mVolt, etc.) represented multipliers of 10 to a
    | negative integer power. So, for example, M is mega and m is
    | milli. In this schma, kilo is a capital K.

    'kilo' always uses a lower case 'k'...

    http://physics.nist.gov/cuu/Units/prefixes.html


    Because the SI prefixes strictly represent powers of 10, they
    should not be used to represent powers of 2. Thus, one kilobit, or
    1 kbit, is 1000 bit and not 210 bit = 1024 bit. To alleviate this
    ambiguity, prefixes for binary multiples have been adopted by the
    International Electrotechnical Commission (IEC) for use in
    information technology.

    => http://physics.nist.gov/cuu/Units/binary.html

    Mainstream usage is different, though (image your favourite computer
    store offering 2048MebiByte-RAM laptops...)

    R'

  12. Re: a problem about memory

    Rainer Weikusat wrote:
    > Robert Harris writes:
    >> [...]
    >> When I was at school, I was taught that capitals (Kbits, MB, etc.)
    >> represented multipliers of 10 to a positive integer power, whereas lower
    >> case letters (mVolt, etc.) represented multipliers of 10 to a negative
    >> integer power. So, for example, M is mega and m is milli. In this schma,
    >> kilo is a capital K.


    R.H. was mis-taught. The upper- and lower-case mnemonic
    *almost* holds: All upper-case prefixes are magnifiers, and
    all "minifiers" are lower-case (yes, is a lower-case letter).
    However, the abbreviations k, h, and da (kilo, hecto, deka; 10^3,
    10^2, 10^1) are all magnifiers despite their case.

    > The usual abbreviation for kilometer is km and for kilogram, it is
    > kg.


    A purely technical quibble: The kilogram is a fundamental
    SI unit, so "1 kg" means "one kilogram" rather than "one thousand
    grams." When using larger or smaller units, though, one never
    combines another prefix with the symbol kg; one behaves as if
    stating quantities in the non-fundamental unit gram, g. Thus,
    a tonne is 1 Mg, not 1 kkg.

    http://physics.nist.gov/cuu/Units/prefixes.html

    When I was a kid we were taught two systems of metric units:
    MKS and CGS, for meter-kilogram-second and centimeter-gram-second,
    naming the principal base units of the respective systems. MKS
    was said to be favored by physicists and astronomers, CGS was the
    choice of chemists and biologists (Wikipedia says otherwise, but
    that's what I was told at the time). The modern SI seems to be a
    formalization of MKS; perhaps the chemists' acid-tongued oratory
    offended the other voting blocs. (It always perplexed me that both
    MKS and CGS involved base units that appeared already multiplied; I
    kept wondering why the obvious MGS system was never adopted.)

    Still, CGS lives on in an old geeky cartoon. I won't attempt
    to reproduce it in ASCII art, so here's a description: At the top
    of the picture is the word "erg," the CGS unit of energy. In the
    middle there's a drawing of a bug lying on its back with its very
    many feet waving helplessly in the air. And below is the explanation:
    "An erg is a dyne centimeter."

    --
    Eric.Sosman@sun.com

  13. Re: a problem about memory

    Ralf Fassel writes:
    > * Robert Harris
    > | When I was at school, I was taught that capitals (Kbits, MB, etc.)
    > | represented multipliers of 10 to a positive integer power, whereas
    > | lower case letters (mVolt, etc.) represented multipliers of 10 to a
    > | negative integer power. So, for example, M is mega and m is
    > | milli. In this schma, kilo is a capital K.
    >
    > 'kilo' always uses a lower case 'k'...
    >
    > http://physics.nist.gov/cuu/Units/prefixes.html
    >
    >
    > Because the SI prefixes strictly represent powers of 10, they
    > should not be used to represent powers of 2. Thus, one kilobit, or
    > 1 kbit, is 1000 bit and not 210 bit = 1024 bit. To alleviate this
    > ambiguity, prefixes for binary multiples have been adopted by the
    > International Electrotechnical Commission (IEC) for use in
    > information technology.
    >

    > => http://physics.nist.gov/cuu/Units/binary.html
    >
    > Mainstream usage is different, though (image your favourite computer
    > store offering 2048MebiByte-RAM laptops...)


    'Mainstream usage', ie 'usage by people not accustomed to deal with
    binary computers' is to use powers of ten as 'usual orders of
    magnitude'. That's just really silly when using binary computers,
    because calculating powers-of-ten requires fairly complicated
    algorithms, while calculating powers-of-two can be done with simple
    shift operations.


  14. Re: a problem about memory

    In article <1222788735.185228@news1nwk>,
    Eric Sosman wrote:

    > Rainer Weikusat wrote:
    > > Robert Harris writes:
    > >> [...]
    > >> When I was at school, I was taught that capitals (Kbits, MB, etc.)
    > >> represented multipliers of 10 to a positive integer power, whereas lower
    > >> case letters (mVolt, etc.) represented multipliers of 10 to a negative
    > >> integer power. So, for example, M is mega and m is milli. In this schma,
    > >> kilo is a capital K.

    >
    > R.H. was mis-taught. The upper- and lower-case mnemonic
    > *almost* holds: All upper-case prefixes are magnifiers, and
    > all "minifiers" are lower-case (yes, is a lower-case letter).
    > However, the abbreviations k, h, and da (kilo, hecto, deka; 10^3,
    > 10^2, 10^1) are all magnifiers despite their case.


    The upper/lowercase distinction is used for the initials that would be
    ambiguous because there are two prefixes that start with the same
    letter, e.g. milli and mega. For the ones that aren't ambiguous, either
    case is acceptable.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  15. Re: a problem about memory

    In article ,
    Eric Sosman wrote:

    > Barry Margolin wrote:
    > > In article <1222788735.185228@news1nwk>,
    > > Eric Sosman wrote:
    > >
    > >> Rainer Weikusat wrote:
    > >>> Robert Harris writes:
    > >>>> [...]
    > >>>> When I was at school, I was taught that capitals (Kbits, MB, etc.)
    > >>>> represented multipliers of 10 to a positive integer power, whereas lower
    > >>>> case letters (mVolt, etc.) represented multipliers of 10 to a negative
    > >>>> integer power. So, for example, M is mega and m is milli. In this schma,
    > >>>> kilo is a capital K.
    > >> R.H. was mis-taught. The upper- and lower-case mnemonic
    > >> *almost* holds: All upper-case prefixes are magnifiers, and
    > >> all "minifiers" are lower-case (yes, is a lower-case letter).
    > >> However, the abbreviations k, h, and da (kilo, hecto, deka; 10^3,
    > >> 10^2, 10^1) are all magnifiers despite their case.

    > >
    > > The upper/lowercase distinction is used for the initials that would be
    > > ambiguous because there are two prefixes that start with the same
    > > letter, e.g. milli and mega. For the ones that aren't ambiguous, either
    > > case is acceptable.

    >
    > Not according to SI. Tera is T, not t, giga is G, not g,
    > femto is f, not F. Also, deci and deka are d and da, not d and D.


    So if I wrote that I have 10 tb disk space, you would have trouble
    understanding it? Since there is no lowercase t prefix, what else could
    it mean?

    > Of course, "acceptable" is defined by the acceptor or
    > rejector: You're at liberty to "accept" whatever you like. As
    > long as you don't insist that everyone else accept your abomin--
    > er, idiosyncrasies, it matters not a pp[*] to me.


    According to the dictionary, the only correct spelling of problem is
    "problem". Although spelling it "problm" won't win you a spelling bee,
    you'll still be understood. That's what I mean by "acceptable".

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  16. Re: a problem about memory

    On 2 Oct, 03:25, Barry Margolin wrote:
    > In article ,
    > *Eric Sosman wrote:
    >
    >
    >
    > > Barry Margolin wrote:
    > > > In article <1222788735.185228@news1nwk>,
    > > > *Eric Sosman wrote:

    >
    > > >> Rainer Weikusat wrote:
    > > >>> Robert Harris writes:
    > > >>>> [...]
    > > >>>> When I was at school, I was taught that capitals (Kbits, MB, etc.)
    > > >>>> represented multipliers of 10 to a positive integer power, whereaslower
    > > >>>> case letters (mVolt, etc.) represented multipliers of 10 to a negative
    > > >>>> integer power. So, for example, M is mega and m is milli. In this schma,
    > > >>>> kilo is a capital K.
    > > >> * * *R.H. was mis-taught. *The upper- and lower-case mnemonic
    > > >> *almost* holds: All upper-case prefixes are magnifiers, and
    > > >> all "minifiers" are lower-case (yes, is a lower-case letter).
    > > >> However, the abbreviations k, h, and da (kilo, hecto, deka; 10^3,
    > > >> 10^2, 10^1) are all magnifiers despite their case.

    >
    > > > The upper/lowercase distinction is used for the initials that would be
    > > > ambiguous because there are two prefixes that start with the same
    > > > letter, e.g. milli and mega. *For the ones that aren't ambiguous, either
    > > > case is acceptable.

    >
    > > * * *Not according to SI. *Tera is T, not t, giga is G, not g,
    > > femto is f, not F. *Also, deci and deka are d and da, not d and D.

    >
    > So if I wrote that I have 10 tb disk space, you would have trouble
    > understanding it? *Since there is no lowercase t prefix, what else could
    > it mean?


    Harware with tuberculosis is bad...but 10 cases simultaneously
    is probably fatal. Actually, I would assume you meant
    10 * 2^40 bytes, but be uncertain that you might have only
    meant 10 * 2^37 bytes (10 * 2^40 bits). But if you were a marketing
    person, I would assume you meant 10 ^ 13 bits (since they
    prefer bits because they can inflate the number). The
    whole system is hopelessly ambiguous at this point, since
    you never know if an engineer who understands the binary
    language of moisture vaporators wrote the spec, or
    a marketing wonk. And then there are plenty of allegedly
    technical people who don't understand binary at all.

  17. Re: a problem about memory

    * William Pursell
    | And then there are plenty of allegedly technical people who don't
    | understand binary at all.

    There are 10 kinds of people: those who understand binary,
    and those who don't.

    R'

  18. SI prefixes (Was: Re: a problem about memory)

    Barry Margolin wrote:
    > In article ,
    > Eric Sosman wrote:
    >
    >> Barry Margolin wrote:
    >>> [... concerning SI prefixes ...]
    >>> The upper/lowercase distinction is used for the initials that would be
    >>> ambiguous because there are two prefixes that start with the same
    >>> letter, e.g. milli and mega. For the ones that aren't ambiguous, either
    >>> case is acceptable.

    >> Not according to SI. Tera is T, not t, giga is G, not g,
    >> femto is f, not F. Also, deci and deka are d and da, not d and D.

    >
    > So if I wrote that I have 10 tb disk space, you would have trouble
    > understanding it? Since there is no lowercase t prefix, what else could
    > it mean?


    so if i rot that i hv tentb disk u wd hav trubbl u11g it?
    since thers 0 lc t prefix wht else cd it mean?

    In other words, standards for nomenclature and terminology
    exist for the purpose of reducing the chance for misunderstanding,
    for increasing the chance that a message carries the same meaning
    when received as it had when uttered. In your example, I would
    most likely guess that "t" probably meant "T," but a person who
    requires his readers to guess at his meaning should consider
    dropping engineering and taking up poetry.

    Plus, I'd still be uncertain whether you meant "T" or "Ti"
    (do you have 10 Tb or 10 Tib ~= 11 Tb?). In the context of a disk
    I'd guess that "b" most likely meant "B," and be thankful you
    weren't writing about a networking component where "b" might
    mean "bit" instead.

    >> Of course, "acceptable" is defined by the acceptor or
    >> rejector: You're at liberty to "accept" whatever you like. As
    >> long as you don't insist that everyone else accept your abomin--
    >> er, idiosyncrasies, it matters not a pp[*] to me.

    >
    > According to the dictionary, the only correct spelling of problem is
    > "problem". Although spelling it "problm" won't win you a spelling bee,
    > you'll still be understood. That's what I mean by "acceptable".


    It's good that messages can resist some noise. It's bad to
    inject gratuitous noise.

    --
    Eric Sosman
    esosman@ieee-dot-org.invalid

+ Reply to Thread