32 or 64 bit version of Suse Linux - Suse

This is a discussion on 32 or 64 bit version of Suse Linux - Suse ; houghi wrote: > Peter Köhlmann wrote: >>> AFAIK , one needs a machine with parallel processors (not cores) >>> to do that. Operating system limitation. >>> >> Wrong >> >> http://www.linuxdevices.com/news/NS7543786562.html >> http://www.cyberciti.biz/tips/settin...r-process.html > > As far as I can ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 61

Thread: 32 or 64 bit version of Suse Linux

  1. Re: 32 or 64 bit version of Suse Linux

    houghi wrote:

    > Peter Köhlmann wrote:
    >>> AFAIK, one needs a machine with parallel processors (not cores)
    >>> to do that. Operating system limitation.
    >>>

    >> Wrong
    >>
    >> http://www.linuxdevices.com/news/NS7543786562.html
    >>

    http://www.cyberciti.biz/tips/settin...r-process.html
    >
    > As far as I can understand, both articles talk about multi-processors,
    > not multi-core
    >
    > houghi


    Which now amounts to the exact same thing. Multi-core is having several
    processors on a single dice

    It simply does not matter if the cores are distributed among several dices
    or if they are all mounted on the same one.
    Although the latter (modern multi-core) has the advantage of faster
    cache-coherency since the signal lines are just inside the one enclosing
    --
    The Day Microsoft makes something that does not suck is probably
    the day they start making vacuum cleaners.


  2. Re: 32 or 64 bit version of Suse Linux

    houghi wrote:
    >
    >
    > Paul J Gans wrote:
    >> AFAIK, one needs a machine with parallel processors (not cores)
    >> to do that. Operating system limitation.

    >
    > Then just re-write the OS. ;-)
    >
    > Are they working on it and what are the advantages?


    To be clear, I would like to know what the advantages are of having a
    process dedicated to a core, instead of switching as t does not, not
    what the advantages are of multicore.

    houghi
    --
    >>>> Run the following from the bashprompt if you have the kernel sources

    for I in `find /usr/src/linux/ -name *.c`; \
    do A=`grep -i -A 1 -B 1 **** $I`;if [ "$A" != "" ]; \
    then printf "$I \n$A \n\n"; fi ;done|less

  3. Re: 32 or 64 bit version of Suse Linux

    houghi wrote:

    > houghi wrote:
    >>
    >>
    >> Paul J Gans wrote:
    >>> AFAIK, one needs a machine with parallel processors (not cores)
    >>> to do that. Operating system limitation.

    >>
    >> Then just re-write the OS. ;-)
    >>
    >> Are they working on it and what are the advantages?

    >
    > To be clear, I would like to know what the advantages are of having a
    > process dedicated to a core, instead of switching as t does not, not
    > what the advantages are of multicore.
    >
    > houghi


    Advantages are only present if that process should never be interrupted, not
    even in a heavily loaded system

    For general purposes one does never need processor affinity
    --
    Law of Probable Dispersal:
    Whatever it is that hits the fan will not be evenly distributed.


  4. Re: 32 or 64 bit version of Suse Linux

    Peter Köhlmann wrote:
    > Advantages are only present if that process should never be interrupted, not
    > even in a heavily loaded system
    >
    > For general purposes one does never need processor affinity


    OK, clear. I have once read an article about the advantages of
    multicore where you would have several hundred cores instead of the 4
    we have now. Think 128 or even 1024 cores.

    Can't find the article unfortunatly.

    houghi
    --
    >>>> Run the following from the bashprompt if you have the kernel sources

    for I in `find /usr/src/linux/ -name *.c`; \
    do A=`grep -i -A 1 -B 1 **** $I`;if [ "$A" != "" ]; \
    then printf "$I \n$A \n\n"; fi ;done|less

  5. Re: 32 or 64 bit version of Suse Linux

    houghi wrote:

    > Peter Köhlmann wrote:
    >> Advantages are only present if that process should never be interrupted,
    >> not even in a heavily loaded system
    >>
    >> For general purposes one does never need processor affinity

    >
    > OK, clear. I have once read an article about the advantages of
    > multicore where you would have several hundred cores instead of the 4
    > we have now. Think 128 or even 1024 cores.
    >
    > Can't find the article unfortunatly.
    >
    > houghi


    Well, if you have the same (or higher) number of cores as processes running,
    you will have in effect processor affinity, since no core needs to
    relinquish a process.
    We are still quite some time away from that, though. I typically have around
    200 processes activ, and any PC with 256 processors will be several years
    in the future
    --
    Any idiot can run XP. And usually does.


  6. Re: 32 or 64 bit version of Suse Linux

    Peter Köhlmann wrote:
    > Well, if you have the same (or higher) number of cores as processes running,
    > you will have in effect processor affinity, since no core needs to
    > relinquish a process.


    Indeed. The main thing that was interesting that each process could be
    sanboxed.

    > We are still quite some time away from that, though. I typically have around
    > 200 processes activ, and any PC with 256 processors will be several years
    > in the future


    I now do not have X running, so it is 127 at this moment. When X is
    running, I get closer to 300.

    houghi
    --
    >>>> Run the following from the bashprompt if you have the kernel sources

    for I in `find /usr/src/linux/ -name *.c`; \
    do A=`grep -i -A 1 -B 1 **** $I`;if [ "$A" != "" ]; \
    then printf "$I \n$A \n\n"; fi ;done|less

  7. Re: 32 or 64 bit version of Suse Linux

    On 2008-09-08, houghi wrote:
    > nobody wrote:
    >>> And here again strange as with me everything works and I just added the
    >>> standard Packman that is in the YaST repo. I just installed MPlayer,
    >>> MPlayer plugin and codec32 and it works.
    >>>

    >>
    >> Guess that is the "problem" as I was trying to install amarok-1.14-10
    >> & not MPlayer.....

    >
    > Amarok was already installed.
    >
    > houghi


    So it was the same here BUT it was the prior version.

  8. Re: 32 or 64 bit version of Suse Linux

    houghi wrote:
    >Paul J Gans wrote:
    >> AFAIK, one needs a machine with parallel processors (not cores)
    >> to do that. Operating system limitation.


    >Then just re-write the OS. ;-)


    >Are they working on it and what are the advantages?


    There are several kinds of parallel processor machines. Which are
    useful depends on the problem being solved. For example I have
    one that has three totally independent parts. Each could be run
    in a separate processor and cut the total running time by about
    a third.

    I have another that is very computationally intense. It fits
    in the secondary chache of the CPU chip and just runs. No
    disk references, no memory references. With a parallel processor
    I could make several totally independent runs.

    With enough processors I could run that last intense process
    and download movies at the same time with no interference at
    all.

    But no hardware or software system can be optimal for all problems.
    For right now, multiple cores on one chip are cheap and very
    useful as we've all noted.

    By the way, my intensive program overheats my main machine. Yes,
    the machine is cooled (fans) but when it was built it was not
    designed for such intense use. I suspect that a good water
    cooler is needed.

    --
    --- Paul J. Gans

  9. Re: 32 or 64 bit version of Suse Linux

    Peter Köhlmann wrote:
    >Paul J Gans wrote:


    >> Chris Cox wrote:
    >>>Paul J Gans wrote:
    >>>...
    >>>>
    >>>> Especially in programs written to be run on a mulitprocessor.
    >>>> Most older programs aren't. The only gain then is that the
    >>>> running program *may* not be interrupted when system processes
    >>>> having nothing to do with the program are run.

    >>
    >>>While true, a quick ps will show that you have more than one PROCESS
    >>>running. And that exploits multiple CPUs... arguably more so than
    >>>just having a few threaded apps.

    >>
    >>>I'd say the benefit for >99% of all users is in speed and smoothness
    >>>WITHOUT any threaded applications.... it makes a HUGE difference.
    >>>Processes are just really fat threads with better isolation and full
    >>>contexts.

    >>
    >> Sure. I get that.
    >>
    >> What does seem to be impossible with a multicore machine is
    >> to dedicate one core to a particular job and then let the other(s)
    >> handle everything else.
    >>
    >> AFAIK, one needs a machine with parallel processors (not cores)
    >> to do that. Operating system limitation.
    >>

    >Wrong


    >http://www.linuxdevices.com/news/NS7543786562.html
    >http://www.cyberciti.biz/tips/settin...r-process.html
    >--
    >Machine-Independent, adj.:
    > Does not run on any existing machine.


    Thanks. That isn't quite the same thing, but it could be useful
    to me.

    Note that current muliple core chips have all processors share the
    same cache, at least as far as I know. This is a serious limitation.

    --
    --- Paul J. Gans

  10. Re: 32 or 64 bit version of Suse Linux

    Peter Köhlmann wrote:
    >houghi wrote:


    >> Peter Köhlmann wrote:
    >>> Advantages are only present if that process should never be interrupted,
    >>> not even in a heavily loaded system
    >>>
    >>> For general purposes one does never need processor affinity

    >>
    >> OK, clear. I have once read an article about the advantages of
    >> multicore where you would have several hundred cores instead of the 4
    >> we have now. Think 128 or even 1024 cores.
    >>
    >> Can't find the article unfortunatly.
    >>
    >> houghi


    >Well, if you have the same (or higher) number of cores as processes running,
    >you will have in effect processor affinity, since no core needs to
    >relinquish a process.
    >We are still quite some time away from that, though. I typically have around
    >200 processes activ, and any PC with 256 processors will be several years
    >in the future


    It would be wasteful to dedicate a core to each process. Most of
    your 200 processes can share a singe core with no timing problems
    at all.

    But cores aren't the same as separate processors. AFAIK multicore
    chips share both level 1 and level 2 caches. Thus a serious program
    running out of the cache (this isn't unusual for small programs
    given the size of level 2 caches these days, can be seriously
    slowed down by the demands of another core processing large
    chunks of information and thus filling the cache and dumping
    its previous contents.

    Further, we humans really do not yet know how to write parallel
    programs that run efficiently. We have no major languages that
    parallelize automatically, nor does anyone know how to do that
    yet.

    The future is rich with promise now that we can no longer make
    things faster by simply increasing the clock speed.


    --
    --- Paul J. Gans

  11. Re: 32 or 64 bit version of Suse Linux

    redsheraton@yahoo.co.uk wrote:
    > Will the 64 bit version of Linux run faster on the above hardware, or
    > will the 32 bit version - or is there any/much difference at all?


    Noone seems to have addressed this question yet:
    on your hardware there won't be much difference in speed, although
    the 32-version may be a little bit faster (as it doesn't have to
    handle "long pointers" just to support memory that isn't there anyway).

    On the other hand more software will run in the 32-bit version then
    in the 64-bit one (example: SUN's Java plugin for web browsers (Firefox
    etc.) doesn't exist yet in a 64-bit version), so unless you see yourself
    exending the memory "real soon now" I would go for the 32-bit version.

    Of course the picture would be different with 4 GB of RAM...

    PS: both versions will handle multiple cores just as well, the
    openSUSE kernel is SMP enabled.
    --
    ************************************************** *****************
    ** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
    ** e-mail: E.J.M.Hartman@tudelft.nl, fax: +31-15-278 7295 **
    ** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
    ************************************************** *****************

  12. Re: 32 or 64 bit version of Suse Linux

    Paul J Gans wrote:

    > Peter Köhlmann wrote:
    >>houghi wrote:

    >
    >>> Peter Köhlmann wrote:
    >>>> Advantages are only present if that process should never be
    >>>> interrupted, not even in a heavily loaded system
    >>>>
    >>>> For general purposes one does never need processor affinity
    >>>
    >>> OK, clear. I have once read an article about the advantages of
    >>> multicore where you would have several hundred cores instead of the 4
    >>> we have now. Think 128 or even 1024 cores.
    >>>
    >>> Can't find the article unfortunatly.
    >>>
    >>> houghi

    >
    >>Well, if you have the same (or higher) number of cores as processes
    >>running, you will have in effect processor affinity, since no core needs
    >>to relinquish a process.
    >>We are still quite some time away from that, though. I typically have
    >>around 200 processes activ, and any PC with 256 processors will be several
    >>years in the future

    >
    > It would be wasteful to dedicate a core to each process. Most of
    > your 200 processes can share a singe core with no timing problems
    > at all.
    >
    > But cores aren't the same as separate processors.


    For all practical purposes, they are

    > AFAIK multicore chips share both level 1 and level 2 caches.


    No. They have dedicated level1 caches, and the level2 cache can be assigned
    on demand. If one core is idle, its share of level2 cache can get assigned
    to other cores

    > Thus a serious program
    > running out of the cache (this isn't unusual for small programs
    > given the size of level 2 caches these days, can be seriously
    > slowed down by the demands of another core processing large
    > chunks of information and thus filling the cache and dumping
    > its previous contents.


    Only, your premise is faulty

    > Further, we humans really do not yet know how to write parallel
    > programs that run efficiently. We have no major languages that
    > parallelize automatically, nor does anyone know how to do that
    > yet.


    Has nothing to do with parallel programming

    > The future is rich with promise now that we can no longer make
    > things faster by simply increasing the clock speed.
    >
    >

    --
    Another name for a Windows tutorial is crash course


  13. Re: 32 or 64 bit version of Suse Linux

    Peter K?hlmann wrote:
    >> But cores aren't the same as separate processors.

    >
    > For all practical purposes, they are


    Not completely, as there is only a SINGLE access to "everything
    outside of the chip", so only one "address setting logic", one
    bus master functionality, etc.
    The cores just aren't completely independant.
    --
    ************************************************** *****************
    ** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
    ** e-mail: E.J.M.Hartman@tudelft.nl, fax: +31-15-278 7295 **
    ** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
    ************************************************** *****************

  14. Re: 32 or 64 bit version of Suse Linux

    Eef Hartman wrote:

    > Peter K?hlmann wrote:
    >>> But cores aren't the same as separate processors.

    >>
    >> For all practical purposes, they are

    >
    > Not completely, as there is only a SINGLE access to "everything
    > outside of the chip", so only one "address setting logic", one
    > bus master functionality, etc.
    > The cores just aren't completely independant.


    Well, that is different for all practical purposes from multiple CPUs?
    Those have to arbitrate access to the I/O-Bus or the memory also.
    For multiple CPUs there is still just *one* IO-bus and just *one* memory

    It simply does not matter for that access, except that cache coherency is
    much easier to achieve for multi-core than using multiple CPUs

    Multiple CPUs aren't "independant" from each other also. Not more than
    multi-core ones
    --
    All parts should go together without forcing. You must remember that the
    parts you are reassembling were disassembled by you. Therefore, if you
    can't get them together again, there must be a reason. By all means,
    do not use a hammer.


  15. Re: 32 or 64 bit version of Suse Linux

    Eef Hartman wrote:
    > Peter K?hlmann wrote:
    >>> But cores aren't the same as separate processors.

    >> For all practical purposes, they are

    >
    > Not completely, as there is only a SINGLE access to "everything
    > outside of the chip", so only one "address setting logic", one
    > bus master functionality, etc.
    > The cores just aren't completely independant.


    They're faster though. They're close together so communication between
    them is faster. Also, they share the cache (at least on Intel) so
    there's no big penalty when a process switches to another core. Linux
    has logic built-in that avoids switching a process to another CPU and
    prefers switching to another core instead because there's no penalty
    (imagine a 4-CPU system with each CPU having 2 cores.)

    To sum it up, multicore is better than multiple CPUs for most cases. I
    imagine there can be some workloads that would work better with multiple
    CPUs, but can't think of one right now.

  16. Re: 32 or 64 bit version of Suse Linux

    Peter Köhlmann wrote:
    >Paul J Gans wrote:


    >> Peter Köhlmann wrote:
    >>>houghi wrote:

    >>
    >>>> Peter Köhlmann wrote:
    >>>>> Advantages are only present if that process should never be
    >>>>> interrupted, not even in a heavily loaded system
    >>>>>
    >>>>> For general purposes one does never need processor affinity
    >>>>
    >>>> OK, clear. I have once read an article about the advantages of
    >>>> multicore where you would have several hundred cores instead of the 4
    >>>> we have now. Think 128 or even 1024 cores.
    >>>>
    >>>> Can't find the article unfortunatly.
    >>>>
    >>>> houghi

    >>
    >>>Well, if you have the same (or higher) number of cores as processes
    >>>running, you will have in effect processor affinity, since no core needs
    >>>to relinquish a process.
    >>>We are still quite some time away from that, though. I typically have
    >>>around 200 processes activ, and any PC with 256 processors will be several
    >>>years in the future

    >>
    >> It would be wasteful to dedicate a core to each process. Most of
    >> your 200 processes can share a singe core with no timing problems
    >> at all.
    >>
    >> But cores aren't the same as separate processors.


    >For all practical purposes, they are


    >> AFAIK multicore chips share both level 1 and level 2 caches.


    >No. They have dedicated level1 caches, and the level2 cache can be assigned
    >on demand. If one core is idle, its share of level2 cache can get assigned
    >to other cores


    I'd like to see a citation for the level 1 caches being
    separate.

    And of course the level 2 cache is shared. That's what I
    said. And if it gets assigned to another core when the
    job you want to favor needs it, you've got a slowdown.

    >> Thus a serious program
    >> running out of the cache (this isn't unusual for small programs
    >> given the size of level 2 caches these days, can be seriously
    >> slowed down by the demands of another core processing large
    >> chunks of information and thus filling the cache and dumping
    >> its previous contents.


    >Only, your premise is faulty


    As I said above, I'd love a citation on that.


    >> Further, we humans really do not yet know how to write parallel
    >> programs that run efficiently. We have no major languages that
    >> parallelize automatically, nor does anyone know how to do that
    >> yet.


    >Has nothing to do with parallel programming


    Huh?

    The fact that we humans don't know how to write parallel programs
    that run effiently has nothing to do with parallel programming?

    The fact that no major languages can parallelize automatically
    has nothing to do with parallel programming?

    Wow! Who'd a thunk it!

    >> The future is rich with promise now that we can no longer make
    >> things faster by simply increasing the clock speed.


    --
    --- Paul J. Gans

  17. Re: 32 or 64 bit version of Suse Linux

    Peter Köhlmann wrote:
    >Eef Hartman wrote:


    >> Peter K?hlmann wrote:
    >>>> But cores aren't the same as separate processors.
    >>>
    >>> For all practical purposes, they are

    >>
    >> Not completely, as there is only a SINGLE access to "everything
    >> outside of the chip", so only one "address setting logic", one
    >> bus master functionality, etc.
    >> The cores just aren't completely independant.


    >Well, that is different for all practical purposes from multiple CPUs?
    >Those have to arbitrate access to the I/O-Bus or the memory also.
    >For multiple CPUs there is still just *one* IO-bus and just *one* memory


    >It simply does not matter for that access, except that cache coherency is
    >much easier to achieve for multi-core than using multiple CPUs


    >Multiple CPUs aren't "independant" from each other also. Not more than
    >multi-core ones


    As I said in an earlier post, there are a number of ways to
    build parallel machines. As I said earlier it depends on
    the problem you want to solve.

    One major sort of machine uses separate RAM for each processor
    as well as allowing access to a general memory.

    With separate processors you can build a machine any way you
    want. Each type takes a different type of OS, some linux based,
    some not.

    Most of us can't afford to go that route, so what is cost effective
    for us is a multicore machine with a large cache. Intel, for example,
    has those, but they cost much dollars.

    --
    --- Paul J. Gans

  18. Re: 32 or 64 bit version of Suse Linux

    Paul J Gans wrote:

    > Peter Köhlmann wrote:
    >>Paul J Gans wrote:

    >
    >>> Peter Köhlmann wrote:
    >>>>houghi wrote:
    >>>
    >>>>> Peter Köhlmann wrote:
    >>>>>> Advantages are only present if that process should never be
    >>>>>> interrupted, not even in a heavily loaded system
    >>>>>>
    >>>>>> For general purposes one does never need processor affinity
    >>>>>
    >>>>> OK, clear. I have once read an article about the advantages of
    >>>>> multicore where you would have several hundred cores instead of the 4
    >>>>> we have now. Think 128 or even 1024 cores.
    >>>>>
    >>>>> Can't find the article unfortunatly.
    >>>>>
    >>>>> houghi
    >>>
    >>>>Well, if you have the same (or higher) number of cores as processes
    >>>>running, you will have in effect processor affinity, since no core needs
    >>>>to relinquish a process.
    >>>>We are still quite some time away from that, though. I typically have
    >>>>around 200 processes activ, and any PC with 256 processors will be
    >>>>several years in the future
    >>>
    >>> It would be wasteful to dedicate a core to each process. Most of
    >>> your 200 processes can share a singe core with no timing problems
    >>> at all.
    >>>
    >>> But cores aren't the same as separate processors.

    >
    >>For all practical purposes, they are

    >
    >>> AFAIK multicore chips share both level 1 and level 2 caches.

    >
    >>No. They have dedicated level1 caches, and the level2 cache can be
    >>assigned on demand. If one core is idle, its share of level2 cache can get
    >>assigned to other cores

    >
    > I'd like to see a citation for the level 1 caches being
    > separate.


    Good. Google is your friend

    > And of course the level 2 cache is shared. That's what I
    > said.


    No, it is not. You said that both are shared

    > And if it gets assigned to another core when the
    > job you want to favor needs it, you've got a slowdown.


    What part of "idle core" needs more explanation?

    >>> Thus a serious program
    >>> running out of the cache (this isn't unusual for small programs
    >>> given the size of level 2 caches these days, can be seriously
    >>> slowed down by the demands of another core processing large
    >>> chunks of information and thus filling the cache and dumping
    >>> its previous contents.

    >
    >>Only, your premise is faulty

    >
    > As I said above, I'd love a citation on that.
    >

    As I said above, google is your friend
    I am not going to provide readily available facts

    >>> Further, we humans really do not yet know how to write parallel
    >>> programs that run efficiently. We have no major languages that
    >>> parallelize automatically, nor does anyone know how to do that
    >>> yet.

    >
    >>Has nothing to do with parallel programming

    >
    > Huh?
    >
    > The fact that we humans don't know how to write parallel programs
    > that run effiently has nothing to do with parallel programming?
    >
    > The fact that no major languages can parallelize automatically
    > has nothing to do with parallel programming?
    >
    > Wow! Who'd a thunk it!


    Right. Multi-core has nothing to do with parallel programming.
    That is a totally different kettle of fish. Read up (google is again your
    friend) what "parallel programming" is

    >>> The future is rich with promise now that we can no longer make
    >>> things faster by simply increasing the clock speed.

    >


    --
    Clippy: "It looks like you're trying to sue us,
    would you like me to delete all of your files?"


  19. Re: 32 or 64 bit version of Suse Linux

    Paul J Gans wrote:

    > Peter Köhlmann wrote:
    >>Eef Hartman wrote:

    >
    >>> Peter K?hlmann wrote:
    >>>>> But cores aren't the same as separate processors.
    >>>>
    >>>> For all practical purposes, they are
    >>>
    >>> Not completely, as there is only a SINGLE access to "everything
    >>> outside of the chip", so only one "address setting logic", one
    >>> bus master functionality, etc.
    >>> The cores just aren't completely independant.

    >
    >>Well, that is different for all practical purposes from multiple CPUs?
    >>Those have to arbitrate access to the I/O-Bus or the memory also.
    >>For multiple CPUs there is still just *one* IO-bus and just *one* memory

    >
    >>It simply does not matter for that access, except that cache coherency is
    >>much easier to achieve for multi-core than using multiple CPUs

    >
    >>Multiple CPUs aren't "independant" from each other also. Not more than
    >>multi-core ones

    >
    > As I said in an earlier post, there are a number of ways to
    > build parallel machines. As I said earlier it depends on
    > the problem you want to solve.


    Multi-core machines are not "parallel machines"
    Just stop mingling those two concepts. They have very little in common

    < snip irrelevant dribble >
    --
    I don't care who your father is. As long as I am fishing here, you will
    refrain from walking those waters


  20. Re: 32 or 64 bit version of Suse Linux

    On Tue, 9 Sep 2008, Paul J Gans wrote:-

    >Peter Khlmann wrote:
    >>Paul J Gans wrote:


    >>> AFAIK multicore chips share both level 1 and level 2 caches.

    >
    >>No. They have dedicated level1 caches, and the level2 cache can be assigned
    >>on demand. If one core is idle, its share of level2 cache can get assigned
    >>to other cores

    >
    >I'd like to see a citation for the level 1 caches being
    >separate.





    Benefits of the shared cache architecture

    Figure 1 shows two processors (processor 0 and processor 1) sharing the
    same system bus and system memory. Inside each processor there are two
    CPU cores; each has its own private L1 cache while sharing the L2 cache.
    The benefits of such a shared cache system are many:


    Supposedly[0], Intel is going to follow AMD's cache structure with the
    Nehalem processor where each core gets its own private L1 and L2 caches,
    and all of them share a large L3 cache.

    However, this only applies to the Intel chips. The AMD X2 chips already
    have private L1 and L2 caches.

    >And of course the level 2 cache is shared. That's what I
    >said. And if it gets assigned to another core when the
    >job you want to favor needs it, you've got a slowdown.
    >
    >>> Thus a serious program
    >>> running out of the cache (this isn't unusual for small programs
    >>> given the size of level 2 caches these days, can be seriously
    >>> slowed down by the demands of another core processing large
    >>> chunks of information and thus filling the cache and dumping
    >>> its previous contents.

    >
    >>Only, your premise is faulty

    >
    >As I said above, I'd love a citation on that.


    See above.


    [0]

    Regards,
    David Bolt

    --
    www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
    SUSE 10.1 32b | | openSUSE 10.3 32b | openSUSE 11.0 32b
    | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b
    RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast