00:48 <_whitenotifier-f> [symbiflow.github.io] mithro opened issue #2: Fix issues identified on PageSpeed Insights - https://git.io/Jew2b

03:07 <_whitenotifier-f> [sv-tests] mithro opened issue #425: Split each runner into it's own Travis build stage - https://git.io/JewwZ

15:07 <sf-slack> <acomodi> @litghost I am experiencing an increased amount of time to build the lookahead (full ROI with latest arch-defs master and latest VtR), does this occur to you as well? (time > 1h, while before that it was ~20minutes)

15:08 <litghost> litghost: I have a larger machine (56 cores) and the new lookahead is parallel

15:08 <litghost> acomodi: Can you run the lookahead computation on a bigger machine?

15:09 <litghost> acomodi: Also what do you have VPR_NUM_WORKERS set too?

15:10 <sf-slack> <acomodi> litghost: Sure, it was unset for the build I am running, I'll retry now

15:10 <litghost> acomodi: Sorry I didn't really answer your question. Yes the new lookahead takes long, however because it is parallel, if you have more cores, it will compute faster. Make sure VPR_NUM_WORKERS is set to $(nproc) and it might make it faster.

15:11 <sf-slack> <mkurc> I'm experiencing longer lookahead builds as well. BTW. Is the VPR on Conda repo build with libtbb ?

15:11 <sf-slack> <acomodi> @litghost All clear

15:12 <litghost> mkurc: I believe so? Let me check

15:13 <litghost> mkurc: I believe so, I ran "ldd" on the binary and see libtbb linked in

15:13 <sf-slack> <mkurc> @litghost Ok, thanks

15:14 <litghost> Can you both check how many cores are being used during lookahead computation?

15:14 <litghost> On my machine it pegs all cores at max utilization for ~10+ minutes

15:16 <sf-slack> <mkurc> @litghost Ok, I'll let you know how long it takes once it finishes.

15:22 <_whitenotifier-f> [vtr-verilog-to-routing] mithro opened issue #322: Add a test to check VtR is deterministic - https://git.io/JewSX

15:26 <sf-slack> <max> I'm assuming that ping was a mistake :)

15:36 <_whitenotifier-f> [sv-tests] tgorochowik opened issue #427: A broken basejump_stl submodule causes our travis to fail - https://git.io/JewSd

15:53 <sf-slack> <acomodi> litghost: Full 50-T using 20 cores: `Computing connection box lookahead map took 1192.66 seconds (max_rss 12361.0 MiB, delta_rss +0.0 MiB)`

16:01 <sf-slack> <acomodi> litghost: without the `--clustering_pin_feasibility_filter off` I get a `FAILED Pin Feasibility Filter` for the OSERDES related molecules. I believe this is a architecture definition issue though

17:49 <_whitenotifier-f> [symbiflow-arch-defs] acomodi opened issue #1149: Fasm2bels fails due to orphan_sink - https://git.io/JewQQ

17:50 <litghost> acomodi: 1200 seconds is about right (e.g. ~20 minutes)

18:53 <_whitenotifier-f> [sv-tests] mithro opened issue #429: Look at cloudbuild as a potential CI system? - https://git.io/Jew5C

19:24 <_whitenotifier-f> [vtr-xml-utils] mithro opened issue #5: Make sure stuff still works with xsltproc - https://git.io/Jewds

19:46 <mithro> litghost: You might find http://www.ispd.cc/contests/16/FAQ.html interesting

19:46 <tpb> Title: 2016 ISPD Contest : FAQ (at www.ispd.cc)

19:46 <mithro> ISPD 2016 : Routability-Driven FPGA Placement Contest

19:56 <mithro> http://www.ispd.cc/contests/17/index.html might also be interesting -- ISPD 2017 Contest : Clock-Aware FPGA Placement

19:56 <tpb> Title: ISPD 2017 Contest : Clock-Aware FPGA Placement (at www.ispd.cc)

20:07 <_whitenotifier-f> [prjxray] litghost opened issue #1141: Incorrect PLL IN_USE feature - https://git.io/JewFU

20:09 <emily> Is parallel computing allowed? Can I submit Windows binary?

20:09 <emily> No. Only single-thread executable linux-64 is allowed in this contest.

20:09 <emily> but... why (re thread, not windows)

21:19 <sorear> the organizers are folks over 40 who think "parallel programming" is a fad and single-thread performance will increase forever?

21:19 <sorear> this would explain a lot about vendor tools