Re: D2006 Hyperthreading Win32
- From: "Ender" <linuxmustdie@xxxxxxxxxxx>
- Date: Sat, 28 Jan 2006 10:57:08 +0500
"Craig Stuntz [TeamB]" <craig_stuntz@xxxxxxxxxxxxx [a.k.a. acm.org]>
You're under-stating the problem with the old MM. FastMM uses separate locks for small, medium, and large allocations. If a request is unable to obtain a lock for the size it needs, it can try to obtain a lock for a larger size before waiting. The old MM had only a single lock, so it would *always* wait if another thread was working on an allocation. It's not just locking /per se/ which hurts performance, but also the granularity of the lock.
Interesting, what should happen if each thread will have it's own allocation pool with own lock?
.
- Follow-Ups:
- Re: D2006 Hyperthreading Win32
- From: Craig Stuntz [TeamB]
- Re: D2006 Hyperthreading Win32
- From: Oliver Townshend
- Re: D2006 Hyperthreading Win32
- References:
- D2006 Hyperthreading Win32
- From: Mike
- Re: D2006 Hyperthreading Win32
- From: Piotr Szturmaj
- Re: D2006 Hyperthreading Win32
- From: Mike
- Re: D2006 Hyperthreading Win32
- From: Francois Malan
- Re: D2006 Hyperthreading Win32
- From: Craig Stuntz [TeamB]
- Re: D2006 Hyperthreading Win32
- From: Danijel Tkalcec [RTC]
- Re: D2006 Hyperthreading Win32
- From: Craig Stuntz [TeamB]
- Re: D2006 Hyperthreading Win32
- From: Danijel Tkalcec [RTC]
- Re: D2006 Hyperthreading Win32
- From: Craig Stuntz [TeamB]
- D2006 Hyperthreading Win32
- Prev by Date: Re: Program start time
- Next by Date: Re: D2006 Hyperthreading Win32
- Previous by thread: Re: D2006 Hyperthreading Win32
- Next by thread: Re: D2006 Hyperthreading Win32
- Index(es):
Relevant Pages
|