HOW TO CUT FAT UNITS IN FAT LIBS NOT FIT IN L2?

Discussion in 'C++' started by 88888 Dihedral, Feb 28, 2012.

  1. After checking some C++ libs, I think now the problem is not the expensive DRAM
    and the HD in tera bytes.

    It is the problem to let executables stayed in L2 in the same chip in nontrivial program executions to beat those hobbists and novices in the execution.

    I regard the cheap DRAM as the slow HD in the 90's.
     
    88888 Dihedral, Feb 28, 2012
    #1
    1. Advertising

  2. 88888 Dihedral

    Quint Rankid Guest

    On Feb 28, 12:24 pm, 88888 Dihedral <>
    wrote:
    > After checking some C++ libs, I think  now the problem is not the expensive DRAM
    > and the HD in tera bytes.
    >
    > It is the problem to let executables stayed in L2 in the same chip  in nontrivial program executions to beat those hobbists and novices in the execution.



    It's not clear to me what you want to accomplish.

    Do you wish to reduce the size of your executables? I've heard that
    some compilers have an option for this. Maybe the linkers do too?

    Wouldn't whatever is in L2 cache get rolled out somewhere if another
    program needs it?

    >
    > I regard the cheap DRAM as the slow HD in the 90's.


    Maybe you should look into some sort of semiconductor based HD? Or is
    that an oxymoron?

    Please clarify.
     
    Quint Rankid, Feb 28, 2012
    #2
    1. Advertising

  3. 88888 Dihedral <> wrote:
    > After checking some C++ libs, I think now the problem is not the expensive DRAM
    > and the HD in tera bytes.
    >
    > It is the problem to let executables stayed in L2 in the same chip in nontrivial program executions to beat those hobbists and novices in the execution.
    >
    > I regard the cheap DRAM as the slow HD in the 90's.


    I have a nagging suspicion: Are you a bot trying to pass the Turing test?
     
    Juha Nieminen, Feb 28, 2012
    #3
  4. 88888 Dihedral

    Dombo Guest

    Op 28-Feb-12 21:01, Juha Nieminen schreef:
    > 88888 Dihedral<> wrote:
    >> After checking some C++ libs, I think now the problem is not the expensive DRAM
    >> and the HD in tera bytes.
    >>
    >> It is the problem to let executables stayed in L2 in the same chip in nontrivial program executions to beat those hobbists and novices in the execution.
    >>
    >> I regard the cheap DRAM as the slow HD in the 90's.

    >
    > I have a nagging suspicion: Are you a bot trying to pass the Turing test?


    My thoughts exactly.
     
    Dombo, Feb 28, 2012
    #4
  5. 88888 Dihedral

    Ian Collins Guest

    On 02/29/12 09:01 AM, Juha Nieminen wrote:
    > 88888 Dihedral<> wrote:
    >> After checking some C++ libs, I think now the problem is not the expensive DRAM
    >> and the HD in tera bytes.
    >>
    >> It is the problem to let executables stayed in L2 in the same chip in nontrivial program executions to beat those hobbists and novices in the execution.
    >>
    >> I regard the cheap DRAM as the slow HD in the 90's.

    >
    > I have a nagging suspicion: Are you a bot trying to pass the Turing test?


    And failing!

    --
    Ian Collins
     
    Ian Collins, Feb 28, 2012
    #5
  6. 在 2012å¹´2月29日星期三UTC+8上åˆ3æ—¶38分39秒,Quint Rankid写é“:
    > On Feb 28, 12:24 pm, 88888 Dihedral <>
    > wrote:
    > > After checking some C++ libs, I think  now the problem is not the expensive DRAM
    > > and the HD in tera bytes.
    > >
    > > It is the problem to let executables stayed in L2 in the same chip  in nontrivial program executions to beat those hobbists and novices in the execution.

    >
    >
    > It's not clear to me what you want to accomplish.
    >
    > Do you wish to reduce the size of your executables? I've heard that
    > some compilers have an option for this. Maybe the linkers do too?
    >
    > Wouldn't whatever is in L2 cache get rolled out somewhere if another
    > program needs it?
    >
    > >
    > > I regard the cheap DRAM as the slow HD in the 90's.

    >
    > Maybe you should look into some sort of semiconductor based HD? Or is
    > that an oxymoron?
    >
    > Please clarify.




    在 2012å¹´2月29日星期三UTC+8上åˆ3æ—¶38分39秒,Quint Rankid写é“:
    > On Feb 28, 12:24 pm, 88888 Dihedral <>
    > wrote:
    > > After checking some C++ libs, I think  now the problem is not the expensive DRAM
    > > and the HD in tera bytes.
    > >
    > > It is the problem to let executables stayed in L2 in the same chip  in nontrivial program executions to beat those hobbists and novices in the execution.

    >
    >
    > It's not clear to me what you want to accomplish.
    >
    > Do you wish to reduce the size of your executables? I've heard that
    > some compilers have an option for this. Maybe the linkers do too?
    >
    > Wouldn't whatever is in L2 cache get rolled out somewhere if another
    > program needs it?
    >
    > >
    > > I regard the cheap DRAM as the slow HD in the 90's.

    >
    > Maybe you should look into some sort of semiconductor based HD? Or is
    > that an oxymoron?
    >
    > Please clarify.


    OK, lets test programs do repeated random RW for some data in L1, and thenL2, and then the dram, and then the HD first for the current mass producedavailable hardware.


    Then one can think about how to design programs with those parameters
    changed over the time.
     
    88888 Dihedral, Mar 1, 2012
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Christoph
    Replies:
    2
    Views:
    534
    Richard Bos
    Sep 17, 2003
  2. Piet
    Replies:
    0
    Views:
    548
  3. Spiros Bousbouras
    Replies:
    9
    Views:
    345
    David T. Ashley
    Dec 19, 2006
  4. Raman
    Replies:
    5
    Views:
    1,051
    Raman
    May 9, 2008
  5. Greg Hauptmann
    Replies:
    4
    Views:
    203
    Stefano Crocco
    Feb 7, 2009
Loading...

Share This Page