Subj : Re: pthread_create and memory To : comp.programming.threads From : Marcin 'Qrczak' Kowalczyk Date : Wed Mar 16 2005 12:47 pm Giancarlo Niccolai writes: > IMHO this is not generally what untyped VM based languages are meant > for; as they are already quite slower than C (depending on the > context 300 to 1200 times slower, obviously not counting the time > used in C RTL functions, but just the VM loop), My implementation generates C code, there is no VM loop, and thus it's not that much slower than C. A few times slower usually. > Being it possible, it would be also nice to chose the GC type from > the application. The GC type influences the generated code, e.g. the instruction sequence generated for allocation and assignment, ability to coalesce adjacent allocations, assumptions about which addresses can move under which circumstances, conditions under which a write barrier can be skipped etc. And since I don't have a high level interfacing to C yet (it's design is waiting for macros to be implemented), currently various implementation details also influence binding with C. This is unfortunate and should be changed at some time. Changing the GC in a fundamental way would force me to redo much work, so I would be tempted to do it only if it provided very significant benefits [e.g. if someone paid me to do so :-) ]. Since I have no idea how to implement a parallel GC, and it's not clear whether native threads with a GC which stops all threads are worth the effort (given that it could happen 500 times a second), for the foreseeable future my language will continue to have the hybrid of emulated and native threads. Only one thread at a time can access the runtime. A separate native thread is used for callbacks and for marked regions of foreign code which don't access the runtime. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/ .