- The ultimate thread pool - 2 Updates
- Scanning memory forward vs. reverse - 1 Update
- "We are doomed" - 1 Update
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 31 04:45PM +0100 Am 31.01.2024 um 00:19 schrieb Chris M. Thomasson: > MSVC should define _MSC_VER, not exactly sure why clang-cl would be in > the mix. Probably due to: clang-cl does say its _MSC_VER, clang++ for Windows not. clang-cl doesn't define __clang__, clang++ does. But clang-cl does define __llvm__. > https://clang.llvm.org/docs/MSVCCompatibility.html Nothing of what I said. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 31 12:32PM -0800 On 1/31/2024 7:45 AM, Bonita Montero wrote: > But clang-cl does define __llvm__. >> https://clang.llvm.org/docs/MSVCCompatibility.html > Nothing of what I said. I think it is relevant. Also, what's up with all of those pragmas anyway? |
| Vir Campestris <vir.campestris@invalid.invalid>: Jan 31 03:56PM On 28/01/2024 10:19, Bonita Montero wrote: > I'd first have guessed that the prefetchers between the memory-levels > are as effective for both directions. So I'd like to see some results > from you. On my Linux box with an AMD Ryzen 5 3400G it's about 11% slower for the second number. But that's a very about, it's doing something else right now and that's the average from several runs - where the ratio is between 97% and 130%. Andy |
| MarioCCCP <NoliMihiFrangereMentulam@libero.it>: Jan 31 01:17AM +0100 On 22/01/24 12:16, Malcolm McLean wrote: > modules. One of which will be the graphics system, which may > well have requirements beyond simple points in space, but > will include such a requirement. Looking at the variety of image formats, I tend to think that the coordinate system and RAM representation is still the least of the problems, and that colour space representation (bits depths, order, endianness, transparency support) could be even worse. Also, at some point, every library has to interact with the OS to load/unload images into the display driver, which is at best posix-copliant, but still depends a lot on the OS internals. Graphics that wont' show up on screen is not very appealing or useful. Here a lot of graphic SW had to be rewritten migrating from X to Wayland. So RAM representation is really the least hard part. The worse is how to load/save a variety of formats to/from disk, and how to display the results on screen. How to move large block of pixels avoinding flickering, etc Since external libraries handle all this, it's not that difficult to have also its own RAM representation of pixels, vectors and geometry. I think that creating a standard for this won't solve the other main problems. -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti MarioCPPP |
| 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