Dan Sugalski wrote: > The problem perl will always run into is that our executable code counts as > data to CPUs, and lives in the D cache, along with all the data we work on. > Ripping through a few 100K strings'll kill any sort of benefits to keeping > the optree small ... Which is an argument for making it large? ;) I don't think we can do much about cache issues except work on locality. Can we figure out what data is going to be used most by what op stream and put them on the same page? For example, if a regex is applied to an I/O buffer, it would help to allocate the buffer and the regex on the same memory page. - Ken
- Re: pramgas as compile-time-only Chaim Frenkel
- Re: pramgas as compile-time-only Graham Barr
- Re: pramgas as compile-time-only Dan Sugalski
- Re: pramgas as compile-time-only Uri Guttman
- Re: pramgas as compile-time-only Nick Ing-Simmons
- Re: pramgas as compile-time-only Dan Sugalski
- Re: pramgas as compile-time-only Bart Lateur
- Re: pramgas as compile-time-only Dan Sugalski
- Re: pramgas as compile-time-only Bart Lateur
- Re: pramgas as compile-time-only Nick Ing-Simmons
- Re: pramgas as compile-time-only Ken Fox
- Re: pramgas as compile-time-only Dan Sugalski
- Re: pramgas as compile-time-only Chaim Frenkel
- Re: pramgas as compile-time-only Nathan Torkington
- Re: pramgas as compile-time-only Dan Sugalski
- Re: pramgas as compile-time-only Nick Ing-Simmons
- Re: pramgas as compile-time-only Dan Sugalski