- cancel <cl4cft$qeq$1@mozo.cc.purdue.edu> - 4 Updates
- A baffling bug in my bignumber code (expressive C++ dialect) - 8 Updates
- copy-on-write - 5 Updates
| thopfing@purdue.edu: Feb 27 10:45PM This message was cancelled from within Mozilla Thunderbird. |
| alfps@start.no: Feb 27 10:46PM This message was cancelled from within Mozilla Thunderbird. |
| SiemelNaran@REMOVE.att.net: Feb 27 10:47PM This message was cancelled from within Mozilla Thunderbird. |
| john_andronicus@hotmail.com: Feb 27 10:48PM This message was cancelled from within Mozilla Thunderbird. |
| Juha Nieminen <nospam@thanks.invalid>: Feb 27 08:45AM > I decided to do a little challenge we used to give to the students in > Bodø in the mid 1990s: to implement a bignumber class and use it to > compute the Fibonacci sequence up to a ridiculous length. People will scoff at people for posting eg. Windows-only code that uses non-standard libraries exclusive to Windows. And you expect people to just accept your custom dialect? |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 27 09:58AM +0100 On 27.02.2017 09:45, Juha Nieminen wrote: >> compute the Fibonacci sequence up to a ridiculous length. > People will scoff at people for posting eg. Windows-only code that uses > non-standard libraries exclusive to Windows. Where did you see any Windows code? > And you expect people to > just accept your custom dialect? You can try it out. <url: https://github.com/alf-p-steinbach/Expressive-Cpp/> I think I'm honing in on a quite useful dialect, but since this is the first time I do something like this there must surely be much room for improvement, that people can suggest. :) Note: the documentation is the bare minimum so far, but it should be sufficient to get up and running (after all it's a pure header library). Cheers!, - Alf |
| Juha Nieminen <nospam@thanks.invalid>: Feb 27 11:26AM >> People will scoff at people for posting eg. Windows-only code that uses >> non-standard libraries exclusive to Windows. > Where did you see any Windows code? I don't think that what I wrote is that hard to understand. If Windows-specific non-standard code is frowned upon, then why do you expect your custom non-standard language extension be treated any better? >> And you expect people to >> just accept your custom dialect? > You can try it out. And I can try Windows-specific code out. But that doesn't make one iota of a difference with regards to what I said. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 27 01:34PM +0100 On 27.02.2017 12:26, Juha Nieminen wrote: > I don't think that what I wrote is that hard to understand. > If Windows-specific non-standard code is frowned upon, then why do you > expect your custom non-standard language extension be treated any better? Oh. I never expect good treatment. I just offer of myself, what I have, because I believe in communication and positive sum interactions. Again, you can just try this, it's available at GitHub <url: https://github.com/alf-p-steinbach/Expressive-Cpp> I have only compiled it in Windows though, and there's almost a law that what one has not actually tried, /will/ manage to surprise... ;-) Cheers!, - Alf |
| scott@slp53.sl.home (Scott Lurndal): Feb 27 01:37PM >> And you expect people to >> just accept your custom dialect? >You can try it out. Why should we? What possible benefit does it have? |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 27 02:48PM +0100 On 27.02.2017 14:37, Scott Lurndal wrote: >>> just accept your custom dialect? >> You can try it out. > Why should we? What possible benefit does it have? I was replying to Juha; I don't know who you represent, Scott. I'm not asking or begging people to try this. That would be really stupid. I was pointing out, to Juha, in an ongoing conversation, that in order to discuss this library or C++ dialect (whatever), in an informed way, one can simply try it out first. That's what I generally do myself, and I think it's a sensible approach also for others. ;-) Cheers & hth., - Alf |
| scott@slp53.sl.home (Scott Lurndal): Feb 27 04:55PM >>> You can try it out. >> Why should we? What possible benefit does it have? >I was replying to Juha; I don't know who you represent, Scott. I'm honestly asking what is the benefit of this macro-based language built on C++. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 27 08:27PM On 27/02/2017 16:55, Scott Lurndal wrote: >> I was replying to Juha; I don't know who you represent, Scott. > I'm honestly asking what is the benefit of this > macro-based language built on C++. Isn't it clear? Obviously the purpose of "expressive C++ dialect" is to irritate the fuck out of people especially on Usenet. /Flibble |
| "Öö Tiib" <ootiib@hot.ee>: Feb 26 03:31PM -0800 On Sunday, 26 February 2017 23:04:36 UTC+2, Vir Campestris wrote: > parent, but read only? and only copy them when they are written? > That seems reasonably efficient. Although the idea that any page fault > could result in an out of memory error does bother me! That is all true but non-constructive. The CoW is there non-comparable. How you use that fact in implementation of your C++ CoW class? The CoW of fork() is part of how kernel handles virtual memory on Intel architecture. The pages are large, fixed size, (typically 4KiB) and the per-process write protection is supported by MMU of Intel. There are no such run-time write-protection features in C++ and it would be quite pricey to implement that on lot of embedded systems. |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 27 01:32AM +0200 On 26.02.2017 23:04, Vir Campestris wrote: > parent, but read only? and only copy them when they are written? > That seems reasonably efficient. Although the idea that any page fault > could result in an out of memory error does bother me! Yes, this is efficient. And the reason why it is efficient is that there are few false positives when detecting if the page needs to be copied. There are separate machine instructions for modifying and reading the memory, and modifying instructions typically do not appear unless needed. Also, the amount of data to copy is relatively large, like 2MB, not some 10 bytes as typical for std::string. The other problem with std::string (apart from prevailing small strings which do not deserve COW) is that because of its interface one often needs to perform COW also in cases where there is no modification planned or happening. This makes COW bad with std::string in multi-threaded programs. Other classes with better interfaces and larger data can potentially benefit from COW also in multi-threaded programs, similar to fork(). BTW, what makes the COW implementation of fork() very suitable to C++ is that in a multi-threaded C++ programs one basically cannot do *anything* between fork() and subsequent exec(). One cannot for example construct a std::string() or anything else which might require dynamic memory allocation because the memory allocator might contain locks held by other threads which are absent in the new process and cannot release the locks. So about the only thing which you can do after fork() in a multithreaded C++ program is exec(), which means that all the old pages get discarded anyway and there would have been no point in copying them. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Feb 26 08:34PM -0800 On 2/25/2017 7:46 PM, Chris M. Thomasson wrote: > On 2/25/2017 6:38 AM, Öö Tiib wrote: [...] > https://groups.google.com/d/topic/lock-free/acjQ3-89abE/discussion > You can use the original CAS based version by Dmitry Vyukov. > Or, my fast-pathed wait-free alteration: Here is a direct link to the code: http://pastebin.com/raw/mtCh5Zxu |
| Ian Collins <ian-news@hotmail.com>: Feb 27 08:15PM +1300 On 02/27/17 10:04 AM, Vir Campestris wrote: >> hit there. Most programs written nowadays are multi-threaded and so CoW >> is not too good idea most of the time. > Isn't CoW the standard method Linux uses when implementing fork()? It's the way Unix implements fork()! -- Ian |
| Bo Persson <bop@gmb.dk>: Feb 27 01:55PM +0100 On 2017-02-26 22:04, Vir Campestris wrote: > parent, but read only? and only copy them when they are written? > That seems reasonably efficient. Although the idea that any page fault > could result in an out of memory error does bother me! When you create a new process you get a new virtual address space, not shared by the original process. So you now have MORE (virtual) memory than before. What is shared is the physical memory, but that can remapped or swapped out as needed. When you create a thread it is part of the same process, and competes for the same memory resources. And C++ requires that when copying a std::string you should get a potential std::bad_alloc exception immediately, not when using non-const operator[] on one of the strings, sometimes later. Bo Persson |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment