M.M. <m...@W...gazeta.pl> napisał(a):

> Michoo <m...@v...pl> napisał(a):
>
> > On 31.05.2012 01:13, M.M. wrote:
> > > Właśnie zmierzyłem.
> > > Środowisko: linux/qtcreator/i3/jakiś-tani-dysk-2.5cala
> > > Projekt: 44 pliki (h i cpp) łącznie 440kb kodu
> > > Nagłówki biblioteczne: trochę z core qt
> > Akurat QT ma całkiem sensownie rozbite nagłówki na forward deklaracje w
> > głównym i deklaracje dopiero w odpowiednim miejscu.
> >
> > > Czas rebuild-all z opcją -O3 7 sekund.
> > Gratuluję. Ja się ostatnio cieszyłem jak na nowym core i5 projekt zaczął
> > się budować 5 minut zamiast 40.
>
> Hmmm
> 440KB / 7s = x / (40*60s)
> 440KB / 7s * 40 * 60s = x
> x = 150MB
>
> Jeśli kompilowałeś projekt o rozmiarze 150MB to cóż...
>


na warsztacie byla kiedys dyskusja o unity buildach, i raczej
tam przewazala opinia ze to powoduje przyspieszenie ;-)

cytat z jednej stronki:

So after all that, what kind of improvements should expect to find? Well let
me give you a few stats. When the UB was implemented at the game company I
worked for, the build time dropped from 55 minutes to just over 6 minutes.
When I implemented UB in a previous job the build time dropped from 10
minutes to less than 3 minutes. When I put them in place at home the build
times dropped on average by 60%.

ja mam 600k kodu 166 plikow .c i czas kompilacji okolo 2-3 s

aczkolwiek nazwa include.c mi sie nie podoba ja mam main.c


#include <windows.h>
#include <psapi.h> // dla proces memory info
#include <math.h>
#include <stdio.h>
#include <gl\gl.h>
#include <gl\glu.h>
#include <winsock.h>

#include ".lib.utils.tiny.c"
#include ".side.log.c"
#include ".side.qpc.c"
#include ".side.info.c"

#include ".side.rawinput.c"
#include ".side.winsock.server.c"
#include ".side.winsock.client.c"

#include ".side.audio.c"


#include ".draw.blit.c"
#include ".draw.prymitives.c"
#include ".draw.sprites.c"

/*
wiekszosc skipped
*/



#include ".loop.hud.c"
#include ".loop.tests.c"
#include ".loop.c"


#include ".wnd.events.c"
#include ".wnd.idle.c"
#include ".wnd.proc.c"
#include ".wnd.main.c"

to sa jedyen includy reszta projektu to czyste pliki .c
(nazewnictwo nie jest za dobre ale kropka na poczatku chcialem
odroznic pliki frameworka od samych plikow gry bez kropki


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

fir <f...@W...gazeta.pl> napisał(a):

> M.M. <m...@W...gazeta.pl> napisał(a):
>
> > Michoo <m...@v...pl> napisał(a):
> >
> > > On 31.05.2012 01:13, M.M. wrote:
> > > > Właśnie zmierzyłem.
> > > > Środowisko: linux/qtcreator/i3/jakiś-tani-dysk-2.5cala
> > > > Projekt: 44 pliki (h i cpp) łącznie 440kb kodu
> > > > Nagłówki biblioteczne: trochę z core qt
> > > Akurat QT ma całkiem sensownie rozbite nagłówki na forward deklaracje w
> > > głównym i deklaracje dopiero w odpowiednim miejscu.
> > >
> > > > Czas rebuild-all z opcją -O3 7 sekund.
> > > Gratuluję. Ja się ostatnio cieszyłem jak na nowym core i5 projekt
zaczął
> > > się budować 5 minut zamiast 40.
> >
> > Hmmm
> > 440KB / 7s = x / (40*60s)
> > 440KB / 7s * 40 * 60s = x
> > x = 150MB
> >
> > Jeśli kompilowałeś projekt o rozmiarze 150MB to cóż...
> >
>
>
> na warsztacie byla kiedys dyskusja o unity buildach, i raczej
> tam przewazala opinia ze to powoduje przyspieszenie ;-)
>
> cytat z jednej stronki:
>
> So after all that, what kind of improvements should expect to find? Well
let
> me give you a few stats. When the UB was implemented at the game company I
> worked for, the build time dropped from 55 minutes to just over 6 minutes.
> When I implemented UB in a previous job the build time dropped from 10
> minutes to less than 3 minutes. When I put them in place at home the build
> times dropped on average by 60%.
>
> ja mam 600k kodu 166 plikow .c i czas kompilacji okolo 2-3 s
>
> aczkolwiek nazwa include.c mi sie nie podoba ja mam main.c
>
>
> #include <windows.h>
> #include <psapi.h> // dla proces memory info
> #include <math.h>
> #include <stdio.h>
> #include <gl\gl.h>
> #include <gl\glu.h>
> #include <winsock.h>
>
> #include ".lib.utils.tiny.c"
> #include ".side.log.c"
> #include ".side.qpc.c"
> #include ".side.info.c"
>
> #include ".side.rawinput.c"
> #include ".side.winsock.server.c"
> #include ".side.winsock.client.c"
>
> #include ".side.audio.c"
>
>
> #include ".draw.blit.c"
> #include ".draw.prymitives.c"
> #include ".draw.sprites.c"
>
> /*
> wiekszosc skipped
> */
>
>
>
> #include ".loop.hud.c"
> #include ".loop.tests.c"
> #include ".loop.c"
>
>
> #include ".wnd.events.c"
> #include ".wnd.idle.c"
> #include ".wnd.proc.c"
> #include ".wnd.main.c"
>
> to sa jedyen includy reszta projektu to czyste pliki .c
> (nazewnictwo nie jest za dobre ale kropka na poczatku chcialem
> odroznic pliki frameworka od samych plikow gry bez kropki
>

chyba je przerobie (nazewnictwo plikow) ale na raqzie nie mam
pomyslu - jak ktos ma propozycje to moze podac jak wg niego
lepiej ponazywac pliki

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Dnia Thu, 31 May 2012 00:03:50 +0000, M.M. napisal:

> Michoo <m...@v...pl> napisał(a):
>
>> On 31.05.2012 01:13, M.M. wrote:
>> > Właśnie zmierzyłem.
>> > Środowisko: linux/qtcreator/i3/jakiś-tani-dysk-2.5cala Projekt: 44
>> > pliki (h i cpp) łącznie 440kb kodu Nagłówki biblioteczne: trochę z
>> > core qt
>> Akurat QT ma całkiem sensownie rozbite nagłówki na forward deklaracje w
>> głównym i deklaracje dopiero w odpowiednim miejscu.
>>
>> > Czas rebuild-all z opcją -O3 7 sekund.
>> Gratuluję. Ja się ostatnio cieszyłem jak na nowym core i5 projekt
>> zaczął się budować 5 minut zamiast 40.
>
> Hmmm
> 440KB / 7s = x / (40*60s)
> 440KB / 7s * 40 * 60s = x
> x = 150MB
>
> Jeśli kompilowałeś projekt o rozmiarze 150MB to cóż...

Michoo już pisał o tym, że czas kompilacji zależy od kodu.
Mam drobną bibliotekę, która kompiluje się w mniej więcej 7s,
a ma w sumie tylko kilkaset linii na pewno nie kilkaset KB.
Za to wciąga sporo bibliotek w tym z boosta.

Edek

do góry

>
> So after all that, what kind of improvements should expect to find? Well
let
> me give you a few stats. When the UB was implemented at the game company I
> worked for, the build time dropped from 55 minutes to just over 6 minutes.
> When I implemented UB in a previous job the build time dropped from 10
> minutes to less than 3 minutes. When I put them in place at home the build
> times dropped on average by 60%.
>

z tego jak rozumiem tamtejsze wytlumaczenie to brzmi ono mw
tak ze 'otwarc (otworzen) plikow jest tyle ile dyrektyw include' (?)
tj o ile mam 200 plikow i inkluduje je w postaci listy
to mam po prostu dwiescie otwarc plikow, natomiast jak robie z
tego 'rozgalez' (co do ktorego ja nie mam specjalnego
wyobrazenia) i mam sumarycznie 1000 dyrektyw inklude to mam
1000 otwarc plikow - aczkolwiek to jest chyba niespecjalnie
kompletne wytlumaczenie, trzebaby wiedziec dokladnie jak
dziala kompilator i co dokladnie sie tam dzieje



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On Wednesday, May 30, 2012 11:39:45 PM UTC+1, M.M. wrote:

> To jest wszystko racja, ale dlaczego mam si� stara� skr�ci� czas
> kompilacji r�wny 30 sekund do 25 sekund? Cz�sto i tak potrzebuj�
> 2 minuty aby si� zastanowi� przed napisaniem kolejnego kawa�ka.
> Tak na oko to uwiera�a mnie kompilacja dopiero w okolicach 2 minut i
> dopiero wtedy zaczyna�em kombinowa�.

Ale czasy kompilacji moga byc duzo wieksze. Moj projekt w pracy kompiluje sie ok. 10
minut, i to poprzez Incredibuild, rozdzielony na nascie build serwerow.

RW

do góry

Edek Pienkowski <e...@g...com> napisał(a):

> Dnia Thu, 31 May 2012 00:03:50 +0000, M.M. napisal:
>
> > Michoo <m...@v...pl> napisał(a):
> >
> >> On 31.05.2012 01:13, M.M. wrote:
> >> > Właśnie zmierzyłem.
> >> > Środowisko: linux/qtcreator/i3/jakiś-tani-dysk-2.5cala Projekt: 44
> >> > pliki (h i cpp) łącznie 440kb kodu Nagłówki biblioteczne: trochę z
> >> > core qt
> >> Akurat QT ma całkiem sensownie rozbite nagłówki na forward deklaracje w
> >> głównym i deklaracje dopiero w odpowiednim miejscu.
> >>
> >> > Czas rebuild-all z opcją -O3 7 sekund.
> >> Gratuluję. Ja się ostatnio cieszyłem jak na nowym core i5 projekt
> >> zaczął się budować 5 minut zamiast 40.
> >
> > Hmmm
> > 440KB / 7s = x / (40*60s)
> > 440KB / 7s * 40 * 60s = x
> > x = 150MB
> >
> > Jeśli kompilowałeś projekt o rozmiarze 150MB to cóż...
>
> Michoo już pisał o tym, że czas kompilacji zależy od kodu.
> Mam drobną bibliotekę, która kompiluje się w mniej więcej 7s,
> a ma w sumie tylko kilkaset linii na pewno nie kilkaset KB.
> Za to wciąga sporo bibliotek w tym z boosta.
No wiadomo. Zawsze templates kompilowały się wolno.
Pozdrawiam



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Sebastian Biały <h...@p...onet.pl> wrote:

> Uzyskanie któtkich cykli zmiana-kompilacja-debug jest bardzo ważna dla
> komfortu pracy. Te twoje 30 sekund jest zdecydowanie upierdliwe.

Zacznij pisać na terminale płatnicze VeriFone, to zmienisz zdanie ;)

Po skompilowaniu aplikacji trzeba:

1. Zlinkować ją (dwie minuty na moim sprzęcie - Intel Core 2 Duo T7200,
2 GHz, 2 GB RAM)

2. Podpisać ją (specjalny okienkowy tool, bez działającej automatyzacji z
commandline'a, dwa 6-cyfrowe PIN-y dla karty do podpisywania, które trzeba
podać przy każdym podpisywaniu; samo podpisywanie trwa ok. pół minuty)

3. Wejśc do OS menu (kolejny 6-znakowy PIN)

4. Przeklikać się przez OS menu (kilka klawiszy)

5. Wpisać hasło grupy (kolejny 6-znakowy PIN)

6. Wrzucić aplikację (przez USB kilkanaście sekund, przez COM-a 2 minuty,
a drivery do USB działają tylko na WinXP i lubią wywalić bluescreena)

7. Poczekać aż terminal zweryfikuje podpis i odpali aplikację (minuta)

8. W odpowiednim momencie odpalić putty na wirtualny port COM (normalny COM
jest zajęty przez pinpada, a dostępny przez USB rozłącza się przy restarcie
terminala - nie odpalenie tego putty, gdy włączone jest debugowanie, powoduje
freeze terminala, na który pomaga tylko wyjęcie baterii)

Oczywiście emulatora nie ma, a z włączonym debugowaniem po USB zakłócany
jest czytnik kart chipowych i ciągle wyskakują błędy odczytu kart. Po roku
takiego pisania zapomniałem już jak to jest, dwa razy kliknąć i mieć
odpalony program... więc nie narzekajcie że macie źle :)

--
Gof

do góry

In the darkest hour on Thu, 31 May 2012 00:03:50 +0000 (UTC),
M.M. <m...@W...gazeta.pl> screamed:
>> > Właśnie zmierzyłem.
>> > Środowisko: linux/qtcreator/i3/jakiś-tani-dysk-2.5cala
>> > Projekt: 44 pliki (h i cpp) łącznie 440kb kodu
>> > Nagłówki biblioteczne: trochę z core qt
>> Akurat QT ma całkiem sensownie rozbite nagłówki na forward deklaracje w
>> głównym i deklaracje dopiero w odpowiednim miejscu.
>>
>> > Czas rebuild-all z opcją -O3 7 sekund.
>> Gratuluję. Ja się ostatnio cieszyłem jak na nowym core i5 projekt zaczął
>> się budować 5 minut zamiast 40.
>
> Hmmm
> 440KB / 7s = x / (40*60s)
> 440KB / 7s * 40 * 60s = x
> x = 150MB
>
> Jeśli kompilowałeś projekt o rozmiarze 150MB to cóż...
>

Zakładasz, że każdy KB kodu, niezależnie od jego zawartości kompiluje
się tak samo długo. To tak jakby za pomocą wagi malucha w kg/cm? przeliczać
wagę Hummera.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:232B ]
[ 13:27:53 user up 13185 days, 1:22, 1 user, load average: 0.99, 0.18, 0.35 ]

Money is just the poor man's credit card. -- Marshall McLuhan

do góry

On 31.05.2012 02:03, M.M. wrote:
> Michoo<m...@v...pl> napisał(a):
>>> Czas rebuild-all z opcją -O3 7 sekund.
>> Gratuluję. Ja się ostatnio cieszyłem jak na nowym core i5 projekt zaczął
>> się budować 5 minut zamiast 40.
>
> Hmmm
> 440KB / 7s = x / (40*60s)
> 440KB / 7s * 40 * 60s = x
> x = 150MB
>
> Jeśli kompilowałeś projekt o rozmiarze 150MB to cóż...
22kloc, 651686 bajtów. Ale do tego dochodzi boost i inne biblioteki,
więc możliwe, że sumarycznie kompilator ma coś koło tego.

--
Pozdrawiam
Michoo

do góry

On 2012-05-31 02:13, M.M. wrote:
>> On 2012-05-31 01:13, M.M. wrote:
>>> To co piszesz ma znaczenie przy projektach zdecydowanie powyżej 2MB kodu.
>> Cały czas pytam o helloworldy. Dla nich nie ma znaczenia jak bardzo
>> spieprzysz.
> Po co więc używać określenia 'spieprzenie' skoro jak sam przyznajesz to
> nie ma znaczenia?

Możesz spieprzyć bez skutków znaczacych. Ale to dalej spieprzenie. Nie
zachowanie higieny/dyscypliny w małym projekcie powoduje ze to lenistwo
rozpływa się na większe projekty. Wiem bo widzę.

> Poza tym program o rozmiarze 2MB, zwłaszcza gdy
> jest porządnie zaprojektowany, to nie taki hello world, może już robić
> coś całkiem pożytecznego.

To dalej maleństwo.

do góry