| Manfred <noname@add.invalid>: Aug 04 06:30PM +0200 On 8/3/2020 8:37 PM, Lynn McGuire wrote: > far, far better than it was a couple of decades ago."" > Dadgum, we are all getting old. > Lynn The video is interesting, IMO especially in the part where Bjarne talks about some possible future in distributed computing, both with non-shared memory and integration between different processors, like CPUs and GPUs. Having some solid support for this in the language could be quite interesting. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 04 07:17PM +0100 On Mon, 3 Aug 2020 14:01:25 -0700 (PDT) > generics? Then why all those distinctly non-generic functions to_string() > to_wstring(), stoul, stoull, etc.? > "Takin' every wrong direction on his lonely way back home" Not to mention gratuitously breaking valid C++11/14 code in C++17, for no benefit which I am able to discern. |
| legalize+jeeves@mail.xmission.com (Richard): Aug 04 09:13PM [Please do not mail me a copy of your followup] Lynn, I just want to say thanks for sharing these links. I try to read most of them, have almost never heard of any of them :), and usually find them worth my time. Your contributions here make it worth spending the time to come back to the newsgroup, IMO! -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Lynn McGuire <lynnmcguire5@gmail.com>: Aug 04 04:56PM -0500 On 8/4/2020 4:13 PM, Richard wrote: > them worth my time. > Your contributions here make it worth spending the time to come back > to the newsgroup, IMO! You are welcome. I use C++ and F77 almost every day and like to share mentions of them. Lynn |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 04 03:51PM -0700 On 8/4/2020 9:30 AM, Manfred wrote: > CPUs and GPUs. > Having some solid support for this in the language could be quite > interesting. I think so. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 04 09:40AM +0200 >> There are even climate-predictions made with endless chain-calculations. >> And no GPU would ever have 128 bit fp. > Why? They have 64 bit... Because there's no need for it. |
| "Öö Tiib" <ootiib@hot.ee>: Aug 04 01:11AM -0700 On Tuesday, 4 August 2020 10:40:37 UTC+3, Bonita Montero wrote: > >> And no GPU would ever have 128 bit fp. > > Why? They have 64 bit... > Because there's no need for it. No one cares what you think they need. They just need. They need 128 and even 256 bit floating points: <https://link.springer.com/article/10.1007/s10915-012-9679-3> |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 04 11:15AM +0200 > No one cares what you think they need. They just need. > They need 128 and even 256 bit floating points: > <https://link.springer.com/article/10.1007/s10915-012-9679-3> If there would be need for >= 128 bit FP in GPUs there would be >= 128 bit FP in GPUs. |
| "Öö Tiib" <ootiib@hot.ee>: Aug 04 07:51AM -0700 On Tuesday, 4 August 2020 12:15:52 UTC+3, Bonita Montero wrote: > > <https://link.springer.com/article/10.1007/s10915-012-9679-3> > If there would be need for >= 128 bit FP in GPUs there would > be >= 128 bit FP in GPUs. Sure. And so your sentence that "no GPU would ever have 128 bit fp." is false. As pointed article told, people did 128 and 256 bit fp on whole battery of GPUs 8 years ago. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 04 05:26PM +0200 > Sure. And so your sentence that "no GPU would ever have 128 bit > fp." is false. No, it's not false. 128-bit fp-supports means native support, not emulated support. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 04 03:38PM -0700 On 8/4/2020 8:26 AM, Bonita Montero wrote: >> fp." is false. > No, it's not false. 128-bit fp-supports means native support, > not emulated support. 128 native should be a heck of a lot faster than emulating it using, say, two 64 bit floats. |
| Sam <sam@email-scan.com>: Aug 04 07:00AM -0400 RM writes: > } > } > It doesn't work. Strings are found but not erased. Says who? What is your proof that "strings are found but not erased"? |
| RM <robert_magdziarz@wp.pl>: Aug 04 01:59PM +0200 W dniu 03.08.2020 o 17:32, RM pisze: > } > } > It doesn't work. Strings are found but not erased. My mistake. Strings in identifiers[i_variables] were prefixed with $, in identifiers[i_properties] were not. Problem closed. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Aug 04 04:37AM -0700 On Sunday, August 2, 2020 at 3:29:22 PM UTC+1, Manfred wrote: > conventional library calls their header files thoroughly decorate each > function prototype to ensure that the correct ABI convention is enforced > by the compiler. On x86, the function calling conventions were cdecl, stdcall, fastcall, and then with C++ there was also thiscall. However since things went 64-Bit with x86_64, the function calling convention is pretty much always 'ms_abi' or 'sysv_abi'. Making the calling convention a part of the function pointer isn't a big deal: void (*Func)(void) __attribute__(__sysv_abi__); > And then there's the whole chapter about memory protection. On Linux I used "mprotect", and on MS-Windows I use "VirtualProtect" in order to mark the page of memory as executable. It works. > Back to your list above, (1) and (2) should work, if used properly. > I would consider (3) unusable for any serious work - toying is always > free of course. Loads of things started out as toys and went on to become something used extensively worldwide. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Aug 04 04:38AM -0700 On Sunday, August 2, 2020 at 6:10:03 PM UTC+1, Paavo Helde wrote: > duplicated a small part of dynamic loader functionality. Is this meant > as a stress test for antivirus products, to see how capable they are in > detecting suspicious activities? Once I've gotten this working in a very basic way, I'll try to make it more elaborate. I suppose you could say I'm developing a new way of dynamically sharing code. |
| 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