Advantages of a large number of threads cf other approaches?

[Ulf Wiger]

On Thu, 19 Feb 2004 17:56:48 +0100, Ulf Wiger <ulf.wiger@REDACTED> 
wrote:

> On Tue, 17 Feb 2004 19:51:49 -0500, Shawn Pearce <spearce@REDACTED> 
> wrote:
>
>
>> Also due to the effects of the relatively small i-cache on some 
>> processors, a well written emulator can in fact run faster than
>> native code on very big applications.  If the application has very
>> poor cache locatily in its instruction stream (randomly jumping to
>> different functions) the i-cache can have a hard time keeping up.
>> But if you move all of the code into the much larger d-cache (as
>> in the case of an emulator) you can make the emulator fly
>> as a much higher percentage of the application can be stored in the 
>> d-cache.
>
> Some work has been done on improving these aspects of BEAM, partly
> due to Thomas Lindgren's work on low-level profiling of AXD 301
> code, compiled with HiPE, JAM and BEAM. Björn G. took some of
> Thomas's findings to heart and improved the cache hit ratio.


Sorry, I had not intended to send that - not that it contains
sensitive or (to my knowledge) incorrect info, but I didn't
feel like I had much to add to the discussion. My mouse off
and clicked the send button before I could react.

/Uffe

-- 
Ulf Wiger, Senior System Architect
EAB/UPD/S

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.