- [OT] USA solar eclipse Aug.21.2017 - 5 Updates
- reading random bytes from memory - 3 Updates
- question about memory-bandwidth and logical cores - 1 Update
- Faster than Boost, Cereal and Protobuf - 1 Update
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 22 12:17PM -0400 I had a chance to drive from Indianapolis, IN to Princeton, KY and see the solar eclipse in the band of full totality. We wound up about 5 miles away from the center-most area of the darkness band, about 10 miles south-southwest of Pendleton. We were at a little church called Eddy Creek Baptist Church, and there were about 25 people from all over the mid-western US there. We were all strangers who gathered together at a local place to witness this incredible event. I can't describe what it was like to see the sun fully obscured by the moon. The brilliant white light hair halo which went out was beyond anything I've ever seen in pictures of a full solar eclipse. It was so much more white, and almost alive. The Earth went from having quite a bit of light where everything was normally visible to our eyesight, to being in the levels of full eclipse light in only about 10 seconds ... and the change was astounding. It wasn't as dark as I expected, but there was still a lot of light being given from the streaks of hair extending out from the fully eclipsed sun, and the light on the horizon gave some light. I would describe it as when it's nighttime and getting dark and you can't make out details on things any longer, but you can still see they're there. It was much much brighter than the strongest fullest moon I've ever seen. The air cooled quite a bit during the last half of the eclipse, but when it was fully eclipsed it cooled rapidly, to the point where even a slight breeze picked up and it even began to feel a little damp like the start of dew. Crickets began to chirp. A rooster from a nearby farm house begin to crow several times. And there was a full 360 degree sunset-like appearance on the horizon, where every bit of the horizon sky was red and pink. Several people in our group took full 360 panoramic views of that horizon. As the eclipse was approaching, and after it was leaving, the trees left eclipse shaped sun areas on the ground. A lot of people here in Indiana reported seeing that as they were not in the band of totality, but only saw a partial eclipse of about 85% or so. It all went by so quick. We each stood there at the church in full amazement at the moment, what we were seeing, and also what we were feeling. It brought us all to elation, like the biggest smiles and happiest faces. We all commented on how there was so much going on that it was overwhelming. We really needed to hit the rewind button and go back and experience it over again and again to take it all in. ----- I've never experienced anything like it. I went to England in 1996, and I drive through western Canada and Alaska in 2002. Apart from some other driving trips those are the big ones I can remember. This event surpasses the England trip, and is on par with the Alaska trip, though the Alaska trip was ~20 days and we saw so much more, and this was only a two-day event to drive down, witness the eclipse, and drive back. There's another solar eclipse in the USA on Apr.08.2024. It will extend from Texas through to Maine. It passes right through Indianapolis and I live about as close to the center band of eclipse totality for this next eclipse trek as we were there near Princeton, KY on this one. It's nearly seven years away, but I would suggest reserving plans in the back of your mind to witness this event. And if you live in another nation and have the opportunity, go and see your local eclipse in the band of totality. It's an experience you'll never forget, and it is deeply moving on so many levels (its raw beauty, the sense of awe it inspires, and there are emotional and spiritual components as you look up and see this massive thing in the uni- verse where, for a moment, you are able to realize how small you truly are, and how big God's creation truly is). I recommend it for everybody from young kids to aged adults. The range of ages we saw there was around retirement, and down to probably six years old with the grandkids. My son was 13 years old when he saw this one. He'll be 20 on the next one (James 4:15 "Lord willing"). If we're able to see it, it will be exciting for him to see how the two compare with two different sets of age-group eyes and understandings. Thank you, Rick C. Hodgin |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 22 05:57PM On Tue, 2017-08-22, Rick C. Hodgin wrote: > I had a chance to drive from Indianapolis, IN to Princeton, KY > and see the solar eclipse in the band of full totality. [...] Completely offtopic, but that hasn't stopped you before, and it was well written. Thanks, I think. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 22 02:32PM -0400 On 8/22/2017 1:57 PM, Jorgen Grahn wrote: > [...] > Completely offtopic, but that hasn't stopped you before, and it was > well written. Thanks, I think. I'm still moved by it today. It's occupied my thinking. I keep reflecting back on moments. The one that stands out the most was seeing the sun like this: https://i.cbc.ca/1.3084197.1432321306!/fileImage/httpImage/image.jpg_gen/derivatives/16x9_620/solar-eclipse.jpg Of all the images I saw on the first page of Google Images, that's about the most accurate to what I saw in real life. I wasn't in snow though, the view from where I saw it was almost directly overhead. It occurred at 1:20pm or so local time, and the sky was completely clear. The sky looked like this. You could see some stars, but not all. And the horizon went around a lot like this, though it was somewhat different: https://s-media-cache-ak0.pinimg.com/736x/63/a9/94/63a994fd0126f3357bdf4a2e0b50b38f.jpg Maybe a little more like this because the sun was directly overhead and not low on the horizon, so the effect was the same all the way around: https://cdn.geekwire.com/wp-content/uploads/2017/06/170626-alaska-eclipse-630x447.jpg And this final link is where we were. You can look at the Google Street View to see the view I had. It's quite accurate. Those trees in the front of the church had their eclipsed-sun- shaped shadows cast not only onto the ground and sidewalk, but also onto the bricks on the church building, where their effect was elongated and very pronounced. When the eclipse reached about 95%, the light on the church sign turned on. :-) https://www.google.com/maps/@37.0352837,-87.9074522,439m/data=!3m1!1e3 I just can't over how impressive it was. It's left a real mark on my family. Thank you, Rick C. Hodgin |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 22 09:23PM +0100 On 22/08/2017 17:17, Rick C. Hodgin wrote: [snip] > components as you look up and see this massive thing in the uni- > verse where, for a moment, you are able to realize how small you > truly are, and how big God's creation truly is). [snip] But the world is flat according to the Bible yes? Rick, fuck off; until you stop posting religious shite I am not interested in your non-religious posts including those about C++. /Flibble |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 22 04:37PM -0400 On 8/22/2017 4:23 PM, Mr Flibble wrote: >> truly are, and how big God's creation truly is). > [snip] > But the world is flat according to the Bible yes? No. Not even close. Your ignorance of God, of truth, of the true teachings of the Bible (those supplanted in your mind by the lies of the devil who presents his twists and falsenesses to you as though they are truth), will be your undoing, Leigh. It is not God who will condemn you. You will condemn you, because you would not hear the truth. I love you, Leigh. I teach you the way out of condemnation. It is not a shameful thing to come to God and say, "I need help. I need to be forgiven." We are all in the same filled-with-sin boat, and that is why Jesus came in to the world. He came to save us from Hell fire. He came to save us from our sin. He came to forgive all who will come to Him and acknowledge before Him the truth: that you are a sinner, that you have done wrong, and that you need to be forgiven. He invites you to be with Him in eternity, Leigh. All you have to do is acknowledge the truth, and ask forgiveness for your sin. He could not have made it any easier and still given you a choice. Thank you, Rick C. Hodgin |
| Juha Nieminen <nospam@thanks.invalid>: Aug 22 05:53AM > i think you get crash when you will read a ram area where ram is just not pinned CPU's have support for memory protection on the hardware level. This means in practice that if a running process tries to access a memory address it's not marked to be able to access, the CPU will throw an interrupt, which jumps to a routine implemented by the operating system (which typically kills the process and shows a message about the program having accessed an invalid memory address; or something more vague in the case of Windows.) Modern operating systems fully run in this protected mode. It stops programs from accessing memory at will, only allowing them access to what they explicitly allocate from the system. On that note, likewise in modern CPUs (although it has been so for quite a long time), the actual number in a memory address (eg. the actual value of a pointer) has little to nothing to do with the physical location of that memory in the RAM chips. Both the hardware and the operating system freely remap memory addresses to physical RAM locations. |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 22 09:09AM +0300 On 21.08.2017 18:31, fir wrote: >> Paavo > do you know maybe how its in pure c (c has signal.h header and can register some kind of handler - > im to tired now to check it myself, but would like to know if some has easy way to know that) Anything concerning signals is not easy in my experience, doubly so with SIGSEGV. In Windows it is 1000x easier to use IsBadReadPtr() for studying random memory locations. > most ideally i would like to get full info like > "MOV instruction for IP 0x0040_110c tried to read from adress 0x0000_0012 which is page guarded from read" > and then silently continue execution Suggesting to look into gdb sources. Apparently it is capable of running another program in such a fashion, with: handle SIGSEGV nostop nopass Just tested that, as it happens I have a handy module for that which repeatedly reads bytes from random locations in memory. The code originates from times when I still had the illusion that the program could somehow survive illegal memory accesses and that this might be useful for something. I have abandoned this illusion by now. Below you see that gdb is printing out a line for each segfault occurring in my program. You will need to copy that behavior from gdb and add printouts of any additional information you are interested in. altair: ~>gdb ac43 GNU gdb (GDB; openSUSE Leap 42.1) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://bugs.opensuse.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ac43...done. (gdb) handle SIGSEGV nostop nopass Signal Stop Print Pass to program Description SIGSEGV No Yes No Segmentation fault (gdb) run -e 'illegalmemoryaccess()' Starting program: /users/paavo/bin/ac43 -e 'illegalmemoryaccess()' Missing separate debuginfos, use: zypper install glibc-debuginfo-2.19-22.1.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". process 20223 is executing new program: /users/paavo/Acapella/trunk/Production/BuildProducts/Linux/Debug/bin/acapella Missing separate debuginfos, use: zypper install libgcc_s1-debuginfo-5.3.1+r233831-6.1.x86_64 libncurses5-debuginfo-5.9-53.4.x86_64 libstdc++6-debuginfo-5.3.1+r 233831-6.1.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffeff34700 (LWP 20232)] [New Thread 0x7fffef533700 (LWP 20233)] [New Thread 0x7fffee2b1700 (LWP 20234)] [New Thread 0x7fffedab0700 (LWP 20235)] [New Thread 0x7fffed2af700 (LWP 20236)] [New Thread 0x7fffecaae700 (LWP 20237)] [New Thread 0x7fffdffff700 (LWP 20238)] [New Thread 0x7fffdf7fe700 (LWP 20239)] [New Thread 0x7fffdeffd700 (LWP 20240)] [New Thread 0x7fffde7fc700 (LWP 20241)] [New Thread 0x7fffddffb700 (LWP 20242)] [New Thread 0x7fffdd7fa700 (LWP 20243)] [Thread 0x7fffdd7fa700 (LWP 20243) exited] [New Thread 0x7fffdd7fa700 (LWP 20244)] [Thread 0x7fffdd7fa700 (LWP 20244) exited] [New Thread 0x7fffdd7fa700 (LWP 20245)] Acapella (ver. 4.3.0.0) internal SW developer license for PerkinElmer 2017-08-22 08:40:32 1 {0/0} [acapella/debug] "IllegalMemoryAccess() module called, process will be crashed now" |PID=20223|TID=20223|SESS=0| "{immediate}(2) [:: IllegalMemoryAccess]" Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. Thread 1 "acapella" received signal SIGSEGV, Segmentation fault. ... |
| Vir Campestris <vir.campestris@invalid.invalid>: Aug 22 09:32PM +0100 On 22/08/2017 06:53, Juha Nieminen wrote: > a pointer) has little to nothing to do with the physical location of that > memory in the RAM chips. Both the hardware and the operating system freely > remap memory addresses to physical RAM locations. That's probably true of the systems that fir will meet, and it's certainly true of anything bigger than a mobile 'phone. It's _not_ correct for some of the smaller embedded processors and the RTOSes that run on them - there are quite a lot of low end CPUs out there still running in real address mode with no protection. Andy |
| David Brown <david.brown@hesbynett.no>: Aug 22 10:40AM +0200 On 21/08/17 23:08, fir wrote: > you mean there are machines on the market (i mean x86/x64 > architecture) that not multiply memory bandwidth with each physical > cores? That is not what he said - he asked you if you had read about NUMA. Clearly you have not. You should do so. An important point is that /some/ bandwidths scale by physical cores - others do not. Typically each physical core has its own L1 cache, with dedicated bandwidth to that level - the total core-to-L1 bandwidth therefore scales with physical cores. But the bandwidth further out - L2 to L3, L3 to memory - can be grouped by clusters of cores, and may have shared buses out to memory. The level of sharing varies by architecture. Typically Intel has flatter sharing for even and more predictable accesses, while AMD has hierarchies giving better scaling of total memory bandwidth by core count, but less uniform access (hence "NUMA"). |
| woodbrian77@gmail.com: Aug 21 08:51PM -0700 On Monday, August 21, 2017 at 5:43:23 PM UTC-5, Öö Tiib wrote: > > makes it so you can get some results with just one machine. > So measuring serializing and deserializing separately still somehow > makes things too complicated and also can't be done on just one machine? No. I'm not opposed to this idea, but it makes for more work for the benchmark author in terms of coding and presenting the results. |
| 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