Menu
▾
▴
tcl-core
|
From: Daniel H. <da...@gm...> - 2009-03-02 23:19:25
|
Hello, my name is Daniel Hans and I participated in gsoc 2008. Now I attend "open source programs optimization" course at my university. In order to pass I have to write a quite simple optimization for a certain open source program. I thought it would be great to do something for the Tcl community. The aim of my project is to improve effectiveness (time, memory usage, etc.) of a particular aspect of an open source program. Then I have to show that my solution is really somehow better than the existing one by running some tests or something. That would be appreciated to use for example some profiling tools like Google Profiler or gprof. I would like my project to be up to 1500-2500 lines of code. I have already one idea of what to do from Tomasz Kosiak, but I am sure that there are some other things to do. I would be grateful for some other suggestions. Regards, Daniel |
|
From: Donal K. F. <don...@ma...> - 2009-03-03 08:15:43
|
Daniel Hans wrote: > The aim of my project is to improve effectiveness (time, memory usage, etc.) > of a particular aspect of > an open source program. Then I have to show that my solution is really somehow > better than the existing one by running some tests or something. That would be > appreciated to use for example some profiling tools like Google Profiler or > gprof. I would like my project to be up to 1500-2500 lines of code. Chiseling away at the cost of a few of the key structures in Tcl would be a good thing. For example, it would be nice if the cost of namespaces was lower, which Tcl 8.6 uses much more heavily than previous versions. The runtime stack (the entity that is allocated new for each coroutine) might be another area that could do with attention. Actually, one of the best things for the Tcl Maintainers to know would be where the expensive allocations are; evidence-based optimization is better than going on hunches, even for experts. There's also plenty of room for improvement on speed, but that's rather more difficult to do as a small project. Donal. |
|
From: Steve L. <st...@di...> - 2009-03-03 09:34:24
|
On 03/03/2009, at 5:15 PM, Donal K. Fellows wrote: > Daniel Hans wrote: >> The aim of my project is to improve effectiveness (time, memory >> usage, etc.) >> of a particular aspect of >> an open source program. Then I have to show that my solution is >> really somehow >> better than the existing one by running some tests or something. >> That would be >> appreciated to use for example some profiling tools like Google >> Profiler or >> gprof. I would like my project to be up to 1500-2500 lines of code. > > Chiseling away at the cost of a few of the key structures in Tcl would > be a good thing. For example, it would be nice if the cost of > namespaces > was lower, which Tcl 8.6 uses much more heavily than previous > versions. > The runtime stack (the entity that is allocated new for each > coroutine) > might be another area that could do with attention. Actually, one of > the > best things for the Tcl Maintainers to know would be where the > expensive > allocations are; evidence-based optimization is better than going on > hunches, even for experts. Firstly, Daniel's proposal sounds like a splendid project for the GSOC banner. I would suggest that a range of tools be considered, not just the usual suspects (purify et al). One tool I've had success with in the distant past was Parasoft's Insure++ - if there was interest I would be willing to approach Parasoft and see if they would donate a copy to be used in conjunction with GSOC. I have absolutely no qualms using commercial tools on open source software - it's the results that matter :) Steve |
|
From: Daniel H. <da...@gm...> - 2009-03-03 11:35:35
|
Ok, I was quite misunderstood ;-) I am not looking for a GSOC idea. I have to accomplish my project by the beginning of June, so maybe 1500 lines is to many... For example Tomasz Kosiak suggested me to deal with C10k problem in Tcl Channels. Donal, thank you, for your response, I will read about namespaces in Tcl. Best, Daniel 2009/3/3 Steve Landers <st...@di...>: > > On 03/03/2009, at 5:15 PM, Donal K. Fellows wrote: > >> Daniel Hans wrote: >>> >>> The aim of my project is to improve effectiveness (time, memory usage, >>> etc.) >>> of a particular aspect of >>> an open source program. Then I have to show that my solution is really >>> somehow >>> better than the existing one by running some tests or something. That >>> would be >>> appreciated to use for example some profiling tools like Google Profiler >>> or >>> gprof. I would like my project to be up to 1500-2500 lines of code. >> >> Chiseling away at the cost of a few of the key structures in Tcl would >> be a good thing. For example, it would be nice if the cost of namespaces >> was lower, which Tcl 8.6 uses much more heavily than previous versions. >> The runtime stack (the entity that is allocated new for each coroutine) >> might be another area that could do with attention. Actually, one of the >> best things for the Tcl Maintainers to know would be where the expensive >> allocations are; evidence-based optimization is better than going on >> hunches, even for experts. > > Firstly, Daniel's proposal sounds like a splendid project for the GSOC > banner. > > I would suggest that a range of tools be considered, not just the usual > suspects (purify et al). One tool I've had success with in the distant past > was Parasoft's Insure++ - if there was interest I would be willing to > approach Parasoft and see if they would donate a copy to be used in > conjunction with GSOC. > > I have absolutely no qualms using commercial tools on open source software - > it's the results that matter :) > > Steve > > |
|
From: Kieran <ki...@du...> - 2009-03-03 12:26:19
|
Daniel Hans wrote: > Ok, I was quite misunderstood ;-) I am not looking for a GSOC idea. I > have to accomplish my project by the beginning of June, so maybe 1500 > lines is to many... For example Tomasz Kosiak suggested me to deal > with C10k problem in Tcl Channels. > Hello Daniel, FWIW, I'd also like to see Tcl better support huge numbers of socket connections. Not sure if it exactly fits into the scope of your project though. I recently worked on a project where Tcl could not be used for (at least) this reason - it needed to support many thousand clients on UNIX and Tcl's select() based socket polling wasn't likely to cut it (see unix/tclUnixNotify.c). Not sure what the Windows situation is. The difficulty is that even across Unices, there are a variety of select/poll replacements - e.g. epoll, kqueues, /dev/poll each with their own quirks and limitations. The dual BSD/GPL licensed C library libev seems like a promising attempt to offer a unified interface across Linux/Solaris/BSD - see http://software.schmorp.de/pkg/libev.html. Regards, Kieran Elby |
|
From: Jeff H. <je...@ac...> - 2009-03-03 18:25:08
|
Kieran wrote: > Daniel Hans wrote: >> Ok, I was quite misunderstood ;-) I am not looking for a GSOC idea. I >> have to accomplish my project by the beginning of June, so maybe 1500 >> lines is to many... For example Tomasz Kosiak suggested me to deal >> with C10k problem in Tcl Channels. > > FWIW, I'd also like to see Tcl better support huge numbers of socket > connections. Not sure if it exactly fits into the scope of your project > though. > > I recently worked on a project where Tcl could not be used for (at > least) this reason - it needed to support many thousand clients on UNIX > and Tcl's select() based socket polling wasn't likely to cut it (see > unix/tclUnixNotify.c). Not sure what the Windows situation is. > > The difficulty is that even across Unices, there are a variety of > select/poll replacements - e.g. epoll, kqueues, /dev/poll each with > their own quirks and limitations. > > The dual BSD/GPL licensed C library libev seems like a promising attempt > to offer a unified interface across Linux/Solaris/BSD - see > http://software.schmorp.de/pkg/libev.html. +1 on this project idea, and note that the difficulty will be in getting a consistently 'configure'able setup that detects the best policy on the machine you are on. If you wanted the same advances on Windows, it would be integrating davygravy's iocpsock work into the core. That completely drops Win9x support, but that is fine in the 8.6 (even 8.5) codebase. Jeff |
|
From: David G. <dav...@po...> - 2009-03-08 00:07:58
|
Jeff Hobbs wrote: ... > +1 on this project idea, and note that the difficulty will be in getting > a consistently 'configure'able setup that detects the best policy on the > machine you are on. If you wanted the same advances on Windows, it > would be integrating davygravy's iocpsock work into the core. That > completely drops Win9x support, but that is fine in the 8.6 (even 8.5) > codebase. I'm alive, just busy with other stuff completely unrelated to programming. Help with putting ipv6 and any other new protocols such as IrDA, BlueTooth, IPX/SPX, Appletalk, etc.. into [socket] (if only a framework for the others) would be wonderful. And there is asynchronous multi protocol name resolution of all three types (static, dynamic, and persistent). The branch is still there, unfinished. Maybe I can get to it in a months time, maybe not... It really is a large project and way overdo. Getting win9x support back would require a second (or parallel switched at run-time) notification system based around WSAEventSelect() rather than completion ports. Most of the code could be shared as the concept of overlapped usage is the same. |
|
From: Jeff H. <je...@ac...> - 2009-03-08 01:25:54
|
On 7-Mar-09, at 4:07 PM, David Gravereaux wrote: > Getting win9x support back would require a second (or parallel > switched > at run-time) notification system based around WSAEventSelect() rather > than completion ports. Most of the code could be shared as the > concept > of overlapped usage is the same. There is no need or value in the Win9x codebase support anymore. It's totally EOL from MS and if we dropped all the extra pieces in Tcl and Tk that used it, we would improve long term maintainability and likely fix some bugs. Jeff |
|
From: David G. <dav...@po...> - 2009-03-08 05:18:39
|
Jeff Hobbs wrote: > On 7-Mar-09, at 4:07 PM, David Gravereaux wrote: >> Getting win9x support back would require a second (or parallel >> switched >> at run-time) notification system based around WSAEventSelect() rather >> than completion ports. Most of the code could be shared as the >> concept >> of overlapped usage is the same. > > There is no need or value in the Win9x codebase support anymore. It's > totally EOL from MS and if we dropped all the extra pieces in Tcl and > Tk that used it, we would improve long term maintainability and likely > fix some bugs. Agreed. There's a lot of funny use of ReadFile() used by the windows channel drivers when today those handles are waitable and could be switched over to WaitFor..(). The same code could be used for sockets with WSAEventSelect(), too. Instead of two additional threads per pipe or console for managing readable and writable, it could be one thread per 63 pipes. Does WinCE have CreateIoCompletionPort() and GetQueuedCompletionStatus()? |
|
From: Jeff H. <je...@ac...> - 2009-03-08 07:03:34
|
On 7-Mar-09, at 9:18 PM, David Gravereaux wrote: >> There is no need or value in the Win9x codebase support anymore. >> It's totally EOL from MS and if we dropped all the extra pieces in >> Tcl and Tk that used it, we would improve long term >> maintainability and likely fix some bugs. > > Agreed. There's a lot of funny use of ReadFile() used by the > windows channel drivers when today those handles are waitable and > could be switched over to WaitFor..(). The same code could be used > for sockets with WSAEventSelect(), too. Instead of two additional > threads per pipe or console for managing readable and writable, it > could be one thread per 63 pipes. > > Does WinCE have CreateIoCompletionPort() and > GetQueuedCompletionStatus()? Actually, no, AFAIK CE does not yet support IO completion ports. Jeff |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X