Re: [fpc-pascal] Threads executing in sequence instead of parallel
Graeme Geldenhuys wrote: Ah, finally some explanation that makes sence! Thanks Micha, your modified demo does in fact make Linux switch between threads. I also tried the Sleep(0) you mentiond in the Sort Demo. Sleep() didn't do the trick, but using the BurnCPU() method from Demo1 did. Ok, maybe Sleep(0) in sysutils has to use the sched_yield syscall for linux. This may be a feature request to be reported in bug tracker IMHO. Where can I read more about the timeslices to threads under Linux. It obviously works vastly different to Windows (and FreeBSD as someone pointed out). This sounds like an interesting topic and something work understanding. After all, it gave me enough headaches and a false positive - thinking it is a bug. http://kerneltrap.org/node/517/print is an interview with one of the authors, Ingo Molnar. Search for 'timeslice length' if you don't want to read it all :-). Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threads executing in sequence instead of parallel
Graeme Geldenhuys wrote: pointed out). This sounds like an interesting topic and something work understanding. After all, it gave me enough headaches and a false positive - thinking it is a bug. Btw, here is a quote from the interview, default length seems to be 150ms: (it also explains the usefulness of longer timeslices: caches) quote another property of SCHED_BATCH scheduling is the use of much longer timeslices. Eg. right now it's 3 seconds for a default priority SCHED_BATCH task - while normal tasks have 150 msec timeslices. For things like numeric calculations it's good to have as long timeslices as possible, to minimize the effect of cache trashing. Eg. on a sufficiently powerful CPU with a 2 MB L2 cache, the 'population time' of the cache can be as high as 10 milliseconds. So if there are two numeric calculation tasks that both fully utilize the L2 cache (in nonobvious patterns), and which context-switch every 150 milliseconds, then they will waste 10 milliseconds on cache-rebuilding in the first 6% of their timeslice. This shows up as a direct 6% slowdown of the numeric calculation jobs. Now, if SCHED_BATCH is used, and each task has a 3000 milliseconds timeslice, then the cache-rebuild overhead can be at most 0.3% - a far more acceptable number. /quote Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threads executing in sequence instead of parallel
modified demo does in fact make Linux switch between threads. I also tried the Sleep(0) you mentiond in the Sort Demo. Sleep() didn't do the trick, but using the BurnCPU() method from Demo1 did. Ok, maybe Sleep(0) in sysutils has to use the sched_yield syscall for linux. This may be a feature request to be reported in bug tracker IMHO. Ugly. Better define a procedure TryYieldTimeSlice() or so. No need to follow Windowisms with archaic reasons. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threads executing in sequence instead of parallel
Marco van de Voort wrote: Ok, maybe Sleep(0) in sysutils has to use the sched_yield syscall for linux. This may be a feature request to be reported in bug tracker IMHO. Ugly. Better define a procedure TryYieldTimeSlice() or so. No need to follow Windowisms with archaic reasons. Yes agree, thought of this just after sending the email. The implementation might/will call Sleep(0) on the windows platform. Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: Problem translating c code to pascal
Ok, after a lot of headaches and making questions on ##c freenode
channel I found out what that is.
The structure is a NULL-terminated array / table. It was declared like this:
static const handler_rec hw_handlers[] = {
{ hw-app, hw_handle_req },
{ NULL }
};
But that is just the short declaration for something like this:
static const handler_rec hw_handlers[] = {
{ hw-app, hw_handle_req },
{ NULL, NULL }
};
So it´s an array of size 2, where the second element is filled with
NULLs, but it will be interpreted as an array of size 1, because the
last element marks the end of the array.
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: Problem translating c code to pascal
Am Samstag, den 30.09.2006, 11:48 -0300 schrieb Felipe Monteiro de
Carvalho:
Ok, after a lot of headaches and making questions on ##c freenode
channel I found out what that is.
The structure is a NULL-terminated array / table. It was declared like this:
static const handler_rec hw_handlers[] = {
{ hw-app, hw_handle_req },
{ NULL }
};
But that is just the short declaration for something like this:
static const handler_rec hw_handlers[] = {
{ hw-app, hw_handle_req },
{ NULL, NULL }
};
So it´s an array of size 2, where the second element is filled with
NULLs, but it will be interpreted as an array of size 1, because the
last element marks the end of the array.
Thanks for making the explanation public,
Marc
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] presenting fpunit test results
Hi Vincent, Attached is my latest efforts on fpcUnit Test Reports using XSLT. Before, I sent you two versions of the .xsl file. One created a report based on CSS only and the other one based on HTML Tables only. I tested both against my results (around 900 tests) and the CSS version was dog slow!! I then created from scratch a .xsl file generating HTML Tables (small ones) and uses a small CSS file to format (colors, fonts, etc) the generated HTML. The speed is *much* better. Attached is a archive containing the CSS, XSL and sample results files. I also included a small script file (fixup_xml.sh) which inserts a single line into the xml results file, to specify the xslt stylesheet to use. The reason for the script file, is because I didn't what to modify fpcUnit to insert that line automaticaly, as I like to generate different formatted results from the original xml file and need to insert different XSLT stylesheets for that. For example, I generate two different outputs from the same results.xml file. One for HTML results going to my web server and the other, a plain text email, which gets emailed to a newsgroup showing only the summary of the results. This version is much better than the ones I sent you before. A few things are still missing though, but that is due to the data being missing in the xml results. * The test listings need to be grouped by test suites which will allow for a better summaries to be generated. * More attributes need to be added to the test listings to give information like: Did the test pass, fail or give a error. This will allow me to link the summary test listing to the detailed results using the HTML version of the XSLT. * Ignored/Skipped tests still need support - My version of fpcUnit has not been patched yet. Enjoy, and please give me some feedback. Good or bad! Regards, - Graeme - On 19/09/06, Vincent Snijders [EMAIL PROTECTED] wrote: Graeme Geldenhuys schreef: On 9/8/06, Dean Zobec [EMAIL PROTECTED] wrote: At first sight, it seems that the methods StartTest and EndTest of the listeners are the right place where to place the code to do the timings. I guess the right approach would be to add an option at command line or otherwise to add the timing result. Same for the list of the run tests. Thanks for the pointers Dean. I didn't get time today, but should over the weekend. Any progres? Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- There's no place like 127.0.0.1 fpcUnit_Report.tar.gz Description: GNU Zip compressed data ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
