- Small list of perceived flaws of MinGW - 1 Update
- Small list of perceived flaws of MinGW - 1 Update
- [Announcement] New algorithm: intrusive_sort - 5 Updates
- Data-Oriented Design and Avoiding the C++ Object-Oriented - 7 Updates
| scott@slp53.sl.home (Scott Lurndal): Aug 29 08:48PM ram@zedat.fu-berlin.de (Stefan Ram) writes: [snip mingw complaints] > And when do we get valgrind under Windows? It's available for Windows 10, just install WSL and the ubuntu distro. |
| ram@zedat.fu-berlin.de (Stefan Ram): Aug 29 08:16PM The successor of »srand( time( 0 ))« is supposed to be ::std::mt19937 algorithm{ ::std::random_device{}() }; . But with MinGW, a random number generating algorithm initialized in this way always seems to produce the same sequence (AFAIK). GCC now has sanitizers for addresses and UB, but not when you use MinGW (AFAIK). GDB has a TUI (Ctrl-X A) and an embedded Python interpreter, just not when you use the GDB of MinGW (AFAIK). And then there's this requirement to sometimes #define »__USE_MINGW_ANSI_STDIO« just to get a compliant standard I/O (AFAIK). (I just had to write down this collection somewhere before I forget it.) (Of course, I /am/ grateful to the creators of MinGW that something like this is available for Windows at all.) And when do we get valgrind under Windows? |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 29 06:57AM +0200 On 27.08.2018 15:45, Mr Flibble wrote: > parallel in a single operation. An alternative approach using a zip > iterator and std::sort wouldn't work in this case as 'reverse_index()' > is a sparse reverse-lookup array. Not sure I totally grok what you're doing, but it appears to be a technique for having multiple sequences permuted in the same way as that which yields sorted order for a primary sequence? For that I would just make make a sequence of indices and sort that, with a comparison function that consulted the primary sequence values. > intrusive_sort has the same complexity guarantees as std::sort. I remember reading about and discussing a nifty improvement to intrusive sort a year or two or three back. I'm unable to find it now (it doesn't seem to be mentioned in Wikipedia, and Mr. Google is unhelpful), but I /think/ the Boost implementation of something was updated to use the new and more shiny algorithm. So that could be a place to look. > https://github.com/i42output/neolib/blob/master/include/neolib/intrusive_sort.hpp Cheers!, - Alf |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 29 07:49PM +0100 On 29/08/2018 05:57, Alf P. Steinbach wrote: > which yields sorted order for a primary sequence? > For that I would just make make a sequence of indices and sort that, with > a comparison function that consulted the primary sequence values. If you look at the swapper carefully you will see that two of the three swaps are effectively "sorting indices" but it also needs to swap the actual data so that data can be accessed contiguously in sorted order with minimal CPU cache invalidation. I suggest you read my data-oriented design article that I posted about in a separate thread. > and Mr. Google is unhelpful), but I /think/ the Boost implementation of > something was updated to use the new and more shiny algorithm. > So that could be a place to look. I am unaware of any other implementations of what I call "intrusive sort" other than my own implementation. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 29 03:02PM -0400 On 08/29/2018 02:49 PM, Mr Flibble wrote: > I am unaware of any other implementations of what I call "intrusive > sort" other than my own implementation. The concept is not original, Leigh. Here's an idea for a CAlive syntax example I created in Feb 2016: http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/ideas/qsort.txt The idea is for a qsort() algorithm with callbacks to handle each aspect of its operation through custom code that's supplied in the initial call. It allows for jagged data to be sorted without first creating a sanitary list of pointers to it, etc. Many people have had such ideas, Leigh. They've all been good. -- Rick C. Hodgin |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 29 08:17PM +0100 On 29/08/2018 20:02, Rick C. Hodgin wrote: > initial call. It allows for jagged data to be sorted without first > creating a sanitary list of pointers to it, etc. > Many people have had such ideas, Leigh. They've all been good. And Satan invented fossils yes? /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 29 03:57PM -0400 On 08/29/2018 03:17 PM, Mr Flibble wrote: > And Satan invented fossils yes? It is the truth which makes us free, Leigh. So long as you refuse to give the truth any consideration ... you self-condemn your own soul to Hell. -- Rick C. Hodgin |
| boltar@cylonHQ.com: Aug 29 01:59PM On Wed, 29 Aug 2018 13:10:55 GMT >instructions are >all implemented in gates. >Our 64-core ARM64 processor has no microcode. The processor in question was a 68K. ITYF it was microcoded. |
| David Brown <david.brown@hesbynett.no>: Aug 29 05:18PM +0200 >> I haven't insulted you, unless you count quoting your own words back at you. > Being patronising is being insulting however much you'd like to pretend > otherwise. If you think I have been patronising, then I agree that can be insulting. I suppose the comment about your lack of knowledge about cpu design can be taken as patronising. On the other hand, you /did/ put yourself in hole, and then kept digging. >> nonsense when you said it, and nonsense it remains. Smiley or no smiley. > Ok, I think we've now established you really don't understand what tongue in > cheek actually means. Don't worry about. Very drool. |
| David Brown <david.brown@hesbynett.no>: Aug 29 05:24PM +0200 >> all implemented in gates. >> Our 64-core ARM64 processor has no microcode. > The processor in question was a 68K. ITYF it was microcoded. It was in the 68k family - which were originally microcoded. Later members, including the derivative Coldfire, had steadily less microcode. Division was one of relatively few instructions that retained microcode until it was dropped as a hardware instruction in Coldfire cores (at least the ones I used). Microcode is a slow technique from a bygone era in cpu design - it exists in modern designs only where it is very convenient to have a single instruction at the ISA level (usually due to backwards compatibility), the instruction is complex, its speed is irrelevant, and microcoding of some sort can save significant die area. |
| Juha Nieminen <nospam@thanks.invalid>: Aug 29 10:16AM > also be done in microcode on the die itself, otherwise you'd be claiming that > software can execute magic hardware functions that the hardware itself can't > access! Hardware doesn't necessarily always implement the theoretically fastest implementation of complex operations. For example, multiplication (integer or floating point) can be done in one single clock cycle, but that requires a very large amount of chip space (because it requires a staggering amount of transistors). Making a compromise where multiplication takes 2 or 3 clock cycles reduces this physical chip area requirement exponentially. > Ergo, whoever wrote the microcode for the division royally fucked up. There may be other reasons why hardware implementation of something might be slower than an alternative software implementation. One reason might be accuracy, or the exact type of operations that need to be performed in certain exceptional situations. Floating point calculations can be an example of this (where eg. IEEE standard-compliant calculations might require more complex operations than would be necessary for the application at hand). Another good example is the RDRAND opcode in newer Intel processors. Depending on the processor, it can be 20 times slower than Mersenne Twister. On the other hand, there are reasons why it's slower. |
| boltar@cylonHQ.com: Aug 29 03:53PM On Wed, 29 Aug 2018 17:18:33 +0200 >insulting. I suppose the comment about your lack of knowledge about cpu >design can be taken as patronising. On the other hand, you /did/ put >yourself in hole, and then kept digging. No, you decided to argue the toss over semantics in order - presumably - to try and win the point. There is little qualitative difference between microcode and microops however you wish to spin it. >> Ok, I think we've now established you really don't understand what tongue in >> cheek actually means. Don't worry about. >Very drool. I assume that was supposed to be amusing and not simply a typo. I'd give it another go tbh. |
| David Brown <david.brown@hesbynett.no>: Aug 29 05:59PM +0200 > No, you decided to argue the toss over semantics in order - presumably - to > try and win the point. There is little qualitative difference between microcode > and microops however you wish to spin it. There is a huge difference. Read my explanation in another post. If you would rather post wildly wrong statements and have them left uncorrected, then I think you will be disappointed here - people in this group try to correct others. Most of us like it that way. <snipping the rest> |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 29 07:56PM +0100 > are all of 20 lines of code max especially if you're not even going to bother > to explain exactly what 2 of the functions in your swapper actually do. > "Returns a sparse array" is not documentation. It is clear that you totally missed the point my article was making; if you hadn't you would have understood the need for my intrusive_sort algorithm. I suggest you re-read my article but this time with your brain engaged and you will see that what the "swapper" actually does is clearly documented and that the swapper is not actually part of my intrusive_sort algorithm: it is just an example swapper. > Data oriented design never went away in people doing to the metal coding. > There's a good reason the core of most OS's and device drivers are written in C > and assembler, not C++. Data-oriented design was usurped by OOA/D/P in the mainstream application space; OS kernels and device drivers are niche. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| 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