Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #14591 > unrolled thread

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

Back to article view | Back to comp.lang.c++

Contents

  HOW TO CUT FAT UNITS IN FAT LIBS NOT FIT IN L2? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-28 09:24 -0800
    Re: HOW TO CUT FAT UNITS IN FAT LIBS NOT FIT IN L2? Quint Rankid <qbr567@gmail.com> - 2012-02-28 11:38 -0800
      Re: HOW TO CUT FAT UNITS IN FAT LIBS NOT FIT IN L2? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-03-01 01:23 -0800
    Re: HOW TO CUT FAT UNITS IN FAT LIBS NOT FIT IN L2? Juha Nieminen <nospam@thanks.invalid> - 2012-02-28 20:01 +0000
      Re: HOW TO CUT FAT UNITS IN FAT LIBS NOT FIT IN L2? Dombo <dombo@disposable.invalid> - 2012-02-28 22:22 +0100
      Re: HOW TO CUT FAT UNITS IN FAT LIBS NOT FIT IN L2? Ian Collins <ian-news@hotmail.com> - 2012-02-29 10:30 +1300

#14591 — HOW TO CUT FAT UNITS IN FAT LIBS NOT FIT IN L2?

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.
 

[toc] | [next] | [standalone]

#14592

On Feb 28, 12:24 pm, 88888 Dihedral <dihedral88...@googlemail.com>
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.

[toc] | [prev] | [next] | [standalone]

#14642

在 2012年2月29日星期三UTC+8上午3时38分39秒，Quint Rankid写道：
> On Feb 28, 12:24 pm, 88888 Dihedral <dihedral88...@googlemail.com>
> 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 <dihedral88...@googlemail.com>
> 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 then L2, and then the dram, and then the HD first for the current mass produced available hardware. 


Then one can think about how to design programs with those parameters 
changed over the time.

[toc] | [prev] | [next] | [standalone]

#14595

88888 Dihedral <dihedral88888@googlemail.com> 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?

[toc] | [prev] | [next] | [standalone]

#14600

Op 28-Feb-12 21:01, Juha Nieminen schreef:
> 88888 Dihedral<dihedral88888@googlemail.com>  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.

[toc] | [prev] | [next] | [standalone]

#14601

On 02/29/12 09:01 AM, Juha Nieminen wrote:
> 88888 Dihedral<dihedral88888@googlemail.com>  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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web