- Faster than Boost, Cereal and Protobuf - 3 Updates
- questiona about exe (again) - 2 Updates
- question about memory-bandwidth and logical cores - 2 Updates
| "Öö Tiib" <ootiib@hot.ee>: Aug 21 02:05PM -0700 > you wrote. He provides the serialized sizes and the combined > (serialization and deserialization) times. You want to see > it broken down more? In my opinion it's an OK benchmark. Why to combine times of serializing and deserializing that often happen on different hosts and sometimes even on different hardware? |
| woodbrian77@gmail.com: Aug 21 02:33PM -0700 On Monday, August 21, 2017 at 4:05:35 PM UTC-5, Öö Tiib wrote: > > it broken down more? In my opinion it's an OK benchmark. > Why to combine times of serializing and deserializing that often > happen on different hosts and sometimes even on different hardware? Yes, but doing it the way he does simplifies things and makes it so you can get some results with just one machine. |
| "Öö Tiib" <ootiib@hot.ee>: Aug 21 03:42PM -0700 > > happen on different hosts and sometimes even on different hardware? > Yes, but doing it the way he does simplifies things and > 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? |
| Vir Campestris <vir.campestris@invalid.invalid>: Aug 21 09:55PM +0100 On 20/08/2017 21:47, fir wrote: > is really needed) > relative adressin btw would be usefull mostly probably when one would need to optimise code for size, in that case relative adressing would reduce code size but probably in todays x86 reality it is not practical > could someone remember me: as far as i remember calls are non-relative (fixed adress).. but what with loops, when code makes loop is this conditional jump rather to fixed adress or relative -N byted back? same with ifs, do they -+M bytes back/forward or are they rather to fixed code adress? I don't recall whether all the call instructions on x86 are absolute, but I'm pretty sure some of the jumps are relative and some absolute. Bit you ought to be looking at x64 anyway - the 64 bit extended architecture - which has many more addressing modes. x86 is NOT todays reality for most purposes. And you really need to take this to a group that deals with the process and operating system you are interested in. I write cross platform C++, and I certainly do NOT know the answers to those questions on all the processors I use. Andy |
| fir <profesor.fir@gmail.com>: Aug 21 02:23PM -0700 W dniu poniedziałek, 21 sierpnia 2017 22:55:48 UTC+2 użytkownik Vir Campestris napisał: > and I certainly do NOT know the answers to those questions on all the > processors I use. > Andy you shouldnt envelope whorter meanings in longer words in what you wrote only two first lines were meaningful, (where you said its PROBABLY mixed), well maybe it is mixed i will inspect it some day (seem not much important anyway) |
| Vir Campestris <vir.campestris@invalid.invalid>: Aug 21 09:49PM +0100 On 21/08/2017 16:41, fir wrote: > with 2 physical cores whan you do memset you will get it twoce as fast when you use 2 cores [tried it myself belive me] Depends on the exact processor you have. Even different Intel ones will give different results. Did you read about NUMA? Andy |
| fir <profesor.fir@gmail.com>: Aug 21 02:08PM -0700 W dniu poniedziałek, 21 sierpnia 2017 22:49:21 UTC+2 użytkownik Vir Campestris napisał: > give different results. > Did you read about NUMA? > Andy you mean there are machines on the market (i mean x86/x64 architecture) that not multiply memory bandwidth with each physical cores? (if so i would need to be very warned on what not spend my money ;c ) [as membandwidth is totally dritical for system efficiency, in short system efficiency - memory bandwidth] if you have other than x86/x64 i dont much care |
| 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