Prev: hacking
Next: How get percentage of use of cpu
From: Rod Pemberton on 18 Jan 2010 04:31 "Richard Harter" <cri(a)tiac.net> wrote in message news:4b53de37.413140546(a)text.giganews.com... > > The puzzling thing is that Jon is almost certainly familiar with > all of these techiques. That implies that he has something else > in mind. Yeah, that's what I though about providing links to your "old" c.l.c. memory allocator, BGET, and dlmalloc. "He's certainly aware of these... Isn't he?" If not, I'll post links to them upon request, if one can't find one of my old posts with them. RP
From: Rod Pemberton on 18 Jan 2010 04:49 "BGB / cr88192" <cr88192(a)hotmail.com> wrote in message news:hj0uhi$ev9$1(a)news.albasani.net... > > meanwhile, I am off trying to find a way to get my C compile times maybe > 10 or 100x faster by making headers optionally optional... It's a good idea. You just have to remember a few issues might come up: 1) a warning is needed if the library function is used/called without an include and there isn't a function by that name in the program 2) if a header isn't included and there is a function in the program by the same name as the library function, then it's a user function and you shouldn't warn about a missing library include, or link to the C library function. I'm just mentioning this, because this could affect how you parse. E.g., if you decide "malloc" is a keyword since it should reference a C library function, but the user is using his own malloc() and not using the stdlib.h header... I "roll-my-own" quite a bit, especially with ctype.h or string.h functions. I'll use a standard C library function, say strchr(), throughout the code, and then have define sequence to map it to an internal function if the string.h include isn't included: #if 0 #include <string.h> #else #define strchr myfunction #endif RP
From: Calum on 18 Jan 2010 05:49 On Jan 17, 4:33 pm, Jon Harrop <j...(a)ffconsultancy.com> wrote: > Anyone know of a memory allocator that allows blocks to be allocated in > batches? > > -- > Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u If using C++, then the boost::pool allocator may be what you need. http://www.boost.org/doc/libs/1_41_0/libs/pool/doc/index.html It would be helpful to understand: what language you need it for, what problem you are trying to solve (e.g. memory management, simple deallocation, thread safety, multithreaded performance, allocation speed, memory overhead), what are your intended patterns of object allocation/deallocation, and perhaps what you are writing. Calum
From: bartc on 18 Jan 2010 10:24 BGB / cr88192 wrote: > meanwhile, I am off trying to find a way to get my C compile times > maybe 10 or 100x faster by making headers optionally optional... > (IOW: optionally switching to a very different scoping model...). Some of my first compiler attempts used (for good reasons) a memory-resident program, a sort of combined editor/compiler/runner. This way, symbol tables stayed resident and were reused on the next compilation. You just needed a way of clearing the tables relevant to the module being compiled but keeping header-related ones. This wasn't C so header stuff was in a higher scope, which helped. (However if you're talking about your compiler system which, iirc, writes and rereads XML representations between passes, you might want to look at some obvious speed-ups first...) -- Bartc
From: BGB / cr88192 on 18 Jan 2010 13:20
"Rod Pemberton" <do_not_have(a)havenone.cmm> wrote in message news:hj1asv$2rn$1(a)speranza.aioe.org... > "BGB / cr88192" <cr88192(a)hotmail.com> wrote in message > news:hj0uhi$ev9$1(a)news.albasani.net... >> >> meanwhile, I am off trying to find a way to get my C compile times maybe >> 10 or 100x faster by making headers optionally optional... > > It's a good idea. You just have to remember a few issues might come up: > > 1) a warning is needed if the library function is used/called without an > include and there isn't a function by that name in the program > 2) if a header isn't included and there is a function in the program by > the > same name as the library function, then it's a user function and you > shouldn't warn about a missing library include, or link to the C library > function. > yeah. warning about non-existing names will still happen, since in this case there will be no entry in the database either. 2, well, generally compilers don't warn against this, unless the prototype differs or there is some other issue. > I'm just mentioning this, because this could affect how you parse. E.g., > if > you decide "malloc" is a keyword since it should reference a C library > function, but the user is using his own malloc() and not using the > stdlib.h > header... I "roll-my-own" quite a bit, especially with ctype.h or > string.h > functions. I'll use a standard C library function, say strchr(), > throughout > the code, and then have define sequence to map it to an internal function > if > the string.h include isn't included: > > #if 0 > #include <string.h> > #else > #define strchr myfunction > #endif > malloc is a function, and not a keyword. actually, pretty much no functions are keywords, as this would be nasty and a violation of the C standard... (granted, allowing a magic define to make headers optional is also a violation, but nevermond this...). #define _noinclude //magic define that enables this "magic"... granted, there are certain "compiler built-in functions" (such as sin, cos, ....) but these are different... also, the parser does not care about built-in functions anyways, rather, these are noted and handled specially when producing the IL code... |