March 15, 2019 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
March 15, 2019 [00:00:05] <SebasC> btw.. compile your source using --march=native or the builtin's will sometimes compile to a library function instead of the asm instruction :) like __builtin_popcountll... that will take 200x longer without --march=native[00:01:28] <SebasC> like fussy matching integers also cool :) __builtin_popcountll( a & b ) gives you the matching bits of 2 * 64 bits in a few clock cycles :)[00:01:37] <SebasC> I build the sweetest stuff using the builtin's[00:03:21] <bv> does it really make a performance difference compared to using standard C?[00:04:32] <SebasC> depends on the task. but if you know them.. yes these are very high speed[00:05:54] <SebasC> atomics are cool :) oldvalue = __sync_fetch_and_add( &var, 1 ); adds 1 returns old value. newvalue = __sync_add_and_fetch( &var, 10 ); adds 10 returns new value[00:06:11] <SebasC> thats a few clock cycles, safes an entire mutex lock/unlock[00:06:25] <SebasC> infact... this is what mutexes use internally.. so why not use it directly?[00:07:39] <SebasC> this does make a memory barrier sync... so pool those instructions together and you can do many of these with single sync[00:08:13] <bv> I've used C++' std::atomic for my own thread safe queue before finding zmq. that was indeed much faster than locks.[00:08:37] <SebasC> very nice :) same stuff in the asm probally[00:09:49] <SebasC> never forget to make all those vars volatile tho.. this makes code accessing them slower, so use them for interthread communication only :)[00:10:49] <SebasC> you can make thread safe linked lists using 'compare and swap' too :)[00:11:29] <SebasC> start:; take the queue item, add them to next of your new head.. then try replacing the using using swapcompare, but it fails goto start;[00:12:09] <bv> well, this is a level of performance detail I probably won't come to. It looks like 150 kHz of messages would be the max I need to worry about.[00:13:30] <SebasC> Really depends on the use of the application indeed.[00:14:33] <bv> actually, I'm drawn to zmq because it hides all this detail from me! :D[00:14:51] <SebasC> I understand totally :)[00:15:43] <bv> I've been trying to get on top of zproject/zproto last few days.[00:15:44] <SebasC> Only thing missing from zeromq is a userdata struct for the connected addresses in my router... I had to build a radix tree so I could bind my own void *data to the addresses[00:16:48] <SebasC> Had a quick glance at it.. seems more overhead + leaning curve then just building it on the fly[00:17:17] <bv> it was a lot of up front investment. but I'm just about sold on it.[00:18:53] <SebasC> I am sending packed structs over zeromq using the first payload byte to identify them[00:19:10] <SebasC> zero overhead :) only watch out for big/little endianness[00:20:52] <bv> I've been looking at both the zproto based packing and protobuf.[00:20:55] <SebasC> I have to go sleep(25200); only 7 hours sleep untill work tomorrow :)[00:21:04] <bv> sleep well :)[00:21:13] <SebasC> also coding at work xD so 16 hours of coding a day[00:21:18] <SebasC> night night, nice talking to you![00:21:24] <bv> you too![00:21:29] *** SebasC <SebasC!~Sebas@D93EF1AE.cm-28.dynamic.ziggo.nl> has quit IRC (Quit: Leaving)[01:02:12] *** veegee <veegee!~veegee@ipagstaticip-3d3f7614-22f3-5b69-be13-7ab4b2c585d9.sdsl.bell.ca> has quit IRC (Ping timeout: 250 seconds)[05:32:53] *** guido_g <guido_g!~guido_g@ip1f103f9c.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 252 seconds)[06:14:18] *** guido_g <guido_g!~guido_g@ip1f103f9c.dynamic.kabel-deutschland.de> has joined #zeromq[06:29:40] *** cognifloyd <cognifloyd!~cognifloy@072-191-249-006.res.spectrum.com> has quit IRC (Read error: Connection reset by peer)[06:29:51] *** cognifloyd <cognifloyd!~cognifloy@072-191-249-006.res.spectrum.com> has joined #zeromq[09:08:00] *** FabriceB <FabriceB!~FabriceB@lfbn-1-1047-122.w86-247.abo.wanadoo.fr> has quit IRC (Ping timeout: 246 seconds)[09:15:16] *** diorcety <diorcety!~diorcet@109.3.155.170> has joined #zeromq[09:26:06] *** marijnfs_ <marijnfs_!~marijnfs@ppp-93-104-88-21.dynamic.mnet-online.de> has joined #zeromq[09:34:58] *** FabriceB <FabriceB!~FabriceB@mhx-outbound.3ds.com> has joined #zeromq[10:11:52] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #zeromq[10:13:42] *** jimklimov1 <jimklimov1!~jimklimov@31.7.243.238> has joined #zeromq[10:14:36] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)[10:14:38] *** jimklimov1 <jimklimov1!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)[10:14:50] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #zeromq[10:43:34] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)[10:43:56] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #zeromq[11:04:28] *** ged_ <ged_!~ged@deveiate.org> has joined #zeromq[11:05:21] *** ged <ged!~ged@deveiate.org> has quit IRC (Read error: Connection reset by peer)[11:05:23] *** ged_ is now known as ged[11:10:57] *** cognifloyd <cognifloyd!~cognifloy@072-191-249-006.res.spectrum.com> has quit IRC (Ping timeout: 252 seconds)[11:29:32] <marijnfs_> is there a nice way in zeromq to make a bidirectional channel, with only one party doing a connect? As in, many computers can only make outbound connections and receive replys due to router limitations. A REQ socket works well there, but doesn't allow the connectee to freely send messages back.[11:47:35] <bv> You can use two PAIR sockets if you want 1-to-1 or a DEALER/ROUTER if you want m-to-n[11:48:51] <bv> You can also make a proxy that bridges your router and binds both its ends to allow connects from both inside and outside.[12:13:13] *** haasn <haasn!~haasn@HSI-KBW-085-216-096-210.hsi.kabelbw.de> has quit IRC (Ping timeout: 255 seconds)[12:22:19] *** marijnfs_ <marijnfs_!~marijnfs@ppp-93-104-88-21.dynamic.mnet-online.de> has quit IRC (Remote host closed the connection)[12:40:03] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Ping timeout: 252 seconds)[12:45:24] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #zeromq[12:51:08] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Ping timeout: 250 seconds)[13:15:23] *** hello_ <hello_!57434711@gateway/web/freenode/ip.87.67.71.17> has joined #zeromq[13:15:48] *** hello_ <hello_!57434711@gateway/web/freenode/ip.87.67.71.17> has quit IRC (Client Quit)[13:17:14] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #zeromq[13:45:18] *** haasn <haasn!~haasn@HSI-KBW-085-216-096-210.hsi.kabelbw.de> has joined #zeromq[14:57:18] *** bluca <bluca!~bluca@2a01:4b00:f419:6f00:b00c:66c8:99df:336> has joined #zeromq[16:01:23] *** FabriceB_ <FabriceB_!~FabriceB@mhx-outbound.3ds.com> has joined #zeromq[16:03:55] *** FabriceB <FabriceB!~FabriceB@mhx-outbound.3ds.com> has quit IRC (Ping timeout: 252 seconds)[16:03:55] *** FabriceB_ is now known as FabriceB[16:13:41] *** veegee <veegee!~veegee@ipagstaticip-3d3f7614-22f3-5b69-be13-7ab4b2c585d9.sdsl.bell.ca> has joined #zeromq[16:32:32] *** buirg <buirg!~buirg@178.128.75.133> has quit IRC (Remote host closed the connection)[16:33:13] *** buirg <buirg!~buirg@178.128.75.133> has joined #zeromq[16:34:47] *** FabriceB <FabriceB!~FabriceB@mhx-outbound.3ds.com> has quit IRC (Quit: FabriceB)[17:10:26] *** FabriceB <FabriceB!~FabriceB@mhx-outbound.3ds.com> has joined #zeromq[17:12:08] *** FabriceB_ <FabriceB_!~FabriceB@mhx-outbound.3ds.com> has joined #zeromq[17:15:03] *** FabriceB <FabriceB!~FabriceB@mhx-outbound.3ds.com> has quit IRC (Ping timeout: 252 seconds)[17:15:03] *** FabriceB_ is now known as FabriceB[18:21:25] *** cognifloyd <cognifloyd!~cognifloy@072-191-249-006.res.spectrum.com> has joined #zeromq[18:53:07] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Ping timeout: 240 seconds)[18:53:25] *** FabriceB <FabriceB!~FabriceB@mhx-outbound.3ds.com> has quit IRC (Quit: FabriceB)[18:57:09] *** diorcety <diorcety!~diorcet@109.3.155.170> has quit IRC (Quit: Leaving.)[18:57:45] *** diorcety <diorcety!~diorcet@109.3.155.170> has joined #zeromq[18:57:51] *** diorcety <diorcety!~diorcet@109.3.155.170> has quit IRC (Read error: Connection reset by peer)[19:12:47] *** bluca <bluca!~bluca@2a01:4b00:f419:6f00:b00c:66c8:99df:336> has quit IRC (Quit: Leaving.)[19:55:10] *** __alex <__alex!~alex@p4FD3F308.dip0.t-ipconnect.de> has joined #zeromq[20:37:58] *** __alex <__alex!~alex@p4FD3F308.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 245 seconds)[20:51:05] *** __alex <__alex!~alex@p4FD3F308.dip0.t-ipconnect.de> has joined #zeromq[20:58:48] *** __alex <__alex!~alex@p4FD3F308.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 245 seconds)