[14 uur excel berekening]RAM uitbreiding zinnig?

[Verwijderd]

Tweakers,

Ik heb voor mijn werk in VBA / Excel een model gedraaid dat zeer veel en redelijk gecompliceerde berekeningen dient uit te voeren en daardoor op dit moment zo'm 14 uur aan het draaien is. Nu zit er in mijn laptop (IBM, met P4) 1024 mb aan intern geheugen.

Mijn vraag is: als ik dit laat uitbreiden naar 2048 zal dit de berekeningstijd dan aanzienlijk verkorten, of gaat het merendeel van het berekenen over de processor en heeft uitbreiden van het interne geheugen weinig zin?

Gr,

Joost

[internetinfo]

Als je gewoon nog geheugen vrij hebt bij het proces zal je er niks van merken. Als de marge nog maar 100-150 MB is zou ik er pas wat bij zetten.

[Verwijderd]

Berekeningen zijn CPU intensief, onthouden van tabellen en tussenberekeningen kan geheugenintensief zijn.

Draai eens een benchmark van zo'n vergelijkbare VBA/Excel met 1024MB en 512MB - wellicht dat je dan kosteloos al je conclusies daaruit kunt trekken.

Verder: 14 uur op Excel-berekeningen? Volgens mij doen zelfs weersimulaties er tegenwoordig korter over. Wat is dat in vredesnaam voor berekening waar je mee bezig bent?

[ Voor 6% gewijzigd door Verwijderd op 01-07-2004 15:56 ]

[0fbe]

in 14 uur bereken in met me pc een protaine (UD project)
14 uur lijkt me dus echt heel erg overdreven, Wat voor p4 is het?

[IceStorm]

timcooijmans schreef op 01 juli 2004 @ 15:58:
Wat voor p4 is het?

Liever, wat voor berekening is het? Ik kan me niet voorstellen dat je iets wilt waarbij 14 uur Excel stampen de meest efficiente methode is eigenlijk

[Verwijderd]

OK,

de bereking waar het in dit geval omgaat is een financieel model. Op basis van Monte Carlo simulation (voor degenen onder jullie die statistisch onderlegd zijn) die 10000 keer een bepaalde simulatie herhaalt, omzodoende een groot genoeg aantal simulaties te verkrijgen om een gemiddelde te kunnen bepalen dat betrouwbaar is.

Een enkele simulatie bestaat uit een model waarbij een zeer groot aantal aandelen die elk een dagelijkse volatiliteit hebben en ook nog eens alle 16 gecorreleerd zijn voor een aantal jaren voorspeld dienen te worden. Alleen hiervoor zijn er al zo'n honderdduizend berekeningen nodig, en dit dus nog x 10000. En helaas, dit kan niet efficienter......... Dan komt er nog wat Black & Scholes optiewaarderingbij etc. Voor degenen die statistisch en financieel weten waar ik het over heb: een behoorlijk model dus.

Ik las hierboven net een bericht dat je pas zou bij plaatsen als je 100 - 150 mb over hebt, waar kan ik dat zien? In task manager terwijl het model aan het draaien is?

Bedankt alvast voor de reacties so far.

Gr,

Joost

[internetinfo]

Ja, daar kan je zien hoe groot Windows je swap file maakt en je ziet hoeveel geheugen er nog beschikbaar is (bij Fysiek geheugen, bij beschikbaar).

[Verwijderd]

OK,

Zie inderdaad dat er nog de helft van het interne geheugen vrij is maar dat de processor continue tegen de 100% aan zit. Dus misschien dat er ook maar eens een snellere processor in moet.

Vreemd is dat we net de nieuwste IBM laptops hebben (heb hem net een week), geloof dat het de Thinkpad X41 is en zie dat er maar een 1600 processor in zit, wat natuurlijk redelijk laag is.

Weet iemand of deze zonder meer is uit te breiden cq te verhogen tot ....?

Gr,

Joost

[KC_Kaas]

Is het niet niet handiger om zulk soort berekeningen te doen op een kick ass workstation? (dual xeon ofzo) Of moet je perse mobiel zijn?

[Verwijderd]

Ja dat zou zeker makkelijker zijn en sneller, maar helaas hebben alle medewerkers hier een laptop........ Een tweede desktop die alleen geschikt gemaakt is voor dit soort dingen en voor de rest gestript van alle rompslomp zou uiteraard perfect zijn.

Gr,

Joost

[Marco]

Verwijderd schreef op 01 juli 2004 @ 16:45:
Vreemd is dat we net de nieuwste IBM laptops hebben (heb hem net een week), geloof dat het de Thinkpad X41 is en zie dat er maar een 1600 processor in zit, wat natuurlijk redelijk laag is.

Vergeet niet dat het een Centrino processor is, en die zijn vergelijkbaar met een veel snellere desktop-processor.

[TERW_DAN]

delict schreef op 01 juli 2004 @ 20:51:
[...]

Vergeet niet dat het een Centrino processor is, en die zijn vergelijkbaar met een veel snellere desktop-processor.

Jup, ik denk dat juist die cache die een centrino heeft (ze zijn er geloof ik al met 2MB) juist interessant zullen zijn voor de TS. 1GB mem is imho meer dan zat.

[Palomar]

Hou er wel rekening mee dat je laptopje eigenlijk niet geschikt is om constant onder full load te werken. Ja, het kan wel een hele tijd goed gaan, maar het ding wordt loeiheet en als ie té heet wordt gaat ie gewoon uit: weg berekeningen Kun je weer opnieuw beginnen... Vooral in de zomer (nu dus) kan dat best snel gebeuren.

[internetinfo]

Palomar schreef op 01 juli 2004 @ 21:30:
Hou er wel rekening mee dat je laptopje eigenlijk niet geschikt is om constant onder full load te werken. Ja, het kan wel een hele tijd goed gaan, maar het ding wordt loeiheet en als ie té heet wordt gaat ie gewoon uit: weg berekeningen Kun je weer opnieuw beginnen... Vooral in de zomer (nu dus) kan dat best snel gebeuren.

Uitval is pas een latere tegenslag. Als hij warmer wordt gaat hij terugklokken dus gaat het nog langzamer.
Kan je die berekeningen niet splitsen? Als hij continu 100% load heeft gaat 1x draaien langzamer dan 2x met bijvoorbeeld 50% load.

[Fulcrum2000]

Ik heb voor mijn werk in VBA / Excel een model gedraaid dat zeer veel en redelijk gecompliceerde berekeningen dient uit te voeren en daardoor op dit moment zo'm 14 uur aan het draaien is. Nu zit er in mijn laptop (IBM, met P4) 1024 mb aan intern geheugen.

Joost, ik weet niet of er gevoelige informatie in je model staat waardoor je het niet wilt delen, maar ik zou dit model voor de gein best wel eens willen draaien op mijn (tikje opgevoerde) AMD 2800 (zie sig) om een snelheids vergelijk te doen. In deze PC zit zoals je ziet ook 1024 Mb (512 zou ook genoeg zijn), met erg strakke geheugentimings. Ben benieuwd of deze wat van die 14 uur kan afknabbelen

Just let me know. Als je je data niet wilt prijsgeven is het natuurlijk ook ok, gewoon vette pech voor mij dan

[ Voor 5% gewijzigd door Fulcrum2000 op 01-07-2004 21:49 ]

[Palomar]

Fulcrum2000 schreef op 01 juli 2004 @ 21:47:
[...]


Joost, ik weet niet of er gevoelige informatie in je model staat waardoor je het niet wilt delen, maar ik zou dit model voor de gein best wel eens willen draaien op mijn (tikje opgevoerde) AMD 2800 (zie sig) om een snelheids vergelijk te doen. In deze PC zit zoals je ziet ook 1024 Mb (512 zou ook genoeg zijn), met erg strakke geheugentimings. Ben benieuwd of deze wat van die 14 uur kan afknabbelen

Just let me know. Als je je data niet wilt prijsgeven is het natuurlijk ook ok, gewoon vette pech voor mij dan

laten we gewoon een heel cluster gaan maken van l33te opgevoerde GoT PC's zodat die berekening er in 5 minuutjes doorheen is gejaagd

[TERW_DAN]

Palomar schreef op 01 juli 2004 @ 21:30:
Hou er wel rekening mee dat je laptopje eigenlijk niet geschikt is om constant onder full load te werken. Ja, het kan wel een hele tijd goed gaan, maar het ding wordt loeiheet en als ie té heet wordt gaat ie gewoon uit: weg berekeningen Kun je weer opnieuw beginnen... Vooral in de zomer (nu dus) kan dat best snel gebeuren.

Mwah, ligt een beetje aan de notebook, sommige notebooks werken goed onder stressed omstandigheden en flinke temperaturen (mijn notebook staat soms een aantal uren bovenop mijn monitor, bloedheet, maar nooit een hanger). P4s zijn over het algemeen zo gemaakt dat ze zichzelf ook zouden moeten kunnen terugklokken .

* TERW_DAN heeft 3dsmax renders op zijn notebookie gemaakt, geen enkel probleem na een aantal uren flinke load.

[OkselFris]

Je kan veel speculeren over wat uit te breiden en wat zinvol is.

Enigste manier om erachter te komen is de Windows performance monitor draaien en daarmee je geheugen en CPU gebruik te meten.
Als je het juist weet te gebruiken, heb je hiermee het krachtigste tooltje om te kijken of een uitbreiding zinvol is en hoe je systeem gebruikt wordt.

Als je CPU de hele tijd staat te flippen en je geheugen voor de helft in gebruik is, dan kan je al raden wat zinvol is.

[onkl]

Verwijderd schreef op 01 juli 2004 @ 16:20:
Alleen hiervoor zijn er al zo'n honderdduizend berekeningen nodig, en dit dus nog x 10000. En helaas, dit kan niet efficienter......... Dan komt er nog wat Black & Scholes optiewaarderingbij etc. Voor degenen die statistisch en financieel weten waar ik het over heb: een behoorlijk model dus.

Statistisch en financieel durf ik wel mee te praten, maar niet heel erg hard.

Ik durf je wel te voorspellen dat

IceStorm schreef op 01 juli 2004 @ 16:01:
[...]

Liever, wat voor berekening is het? Ik kan me niet voorstellen dat je iets wilt waarbij 14 uur Excel stampen de meest efficiente methode is eigenlijk

Icestorm een punt heeft. De vraag die ik me stel is dan niet of je binnen Excel op de meest functionele manier aan de slag bent.
Wel of Excel de meest functionele manier is.

Ik weet niet of je dit of equivalente modellen vaker zal gebruiken, maar zo ja, zoek eens naar een echt statistisch pakket.
Niets ten nadele van Excel, uitstekend spreadsheetprogramma i.h.a., maar wel een spreadsheetprogramma.
Je kan Excel op duizend en 1 manieren misbruiken waarvoor Microsoft het "niet echt bedoeld heeft", maar accepteer de consequenties, dat zal langzaam gaan omdat Excel hierop niet geoptimaliseerd is, zowel qua geheugenmanagement als qua berekeningen.
Probeer eens proef te draaien op SPSS, SAS etc. achtigen.
Ook voor dat soort programma's zal dit geen 5 seconden klus zijn, maar dan breng je die 14 uur waarschijnlijk flink terug (en het werkt waarschijnlijk nog fijner ook)
Gerede kans dat er *nog* betere programma's bestaan, maar daarmee helpen andere tweakers, google etc. je allicht verder. (ik weet het niet i.i.g.)

Nogmaals, dit verhaal wordt vooral interessant als je dit soort modellen vaker zal gebruiken, maar dat neem ik stiekum maar aan (voor 1 run wacht je even (en dan nog even) en ga je niet een GB RAM kopen.
Mocht je binnen Excel blijven, denkelijk kan je code verder geoptimaliseerd worden.
Willekeurig voorbeeld: roep deze macro aan in plaats van calculate. scheelt een slokje op een borrel.

code:

Sub bereken()
Application.screenupdating=false
Activeworkbook.calculate '<- deze even nakijken (ben "blind" aan't typen)
'uberhaubt een "Doe hier je ding, niet specifiek calculate", 
'neem aan dat je nu ook al VBA gebruikt.
Application.screenupdating=true
end sub()

offtopic:
dit is geloof ik meer een PW achtige reply geworden. hopelijk heb je er toch wat aan..

[dion_b]

Dit is dus idd totaal speculatie tenzij we zeker weten:

a) wat de RAM load is tijdens het draaien

en

b) wat de CPU load is

Daarbij ben ik het roerend eens met onkl, voor zowel RAM als CPU tijd geldt dat je hier met een knoert van een overhead zit te werken omdat je een zeer algemene pick-up truck gebruikt waar je een Ferrari nodig hebt. Hardwarematig de boel aanpakken kan (mits je weet waar de bottlenek zit), maar als dit soort ongein regelmatig gedaan moet wordenis een dedicated, efficitente app (of zelf proggen in Fortran oid)

Iig is dit het soort toepassing waar dingen als dual Xeons of dual Opterons voor ontworpen zijn. Als er vaker dit soort ding gedaan moet worden is een andere (veel simpelere) berekening aan de orde, namelijk hoeveel tijd je extra kwijtbent dit te doen op een notebook tov een flinke (dual-)workstation maal de kosten per uur. Als dat duurder is dan een workstation, heb je een leuke (en onderbouwde!) upgrade

P.s. zie de GoT Huisregels- wij tweakers doen elkaar constant de groeten, dus hoef je niet 'Gr, Joost' onder iedere post te zetten. Mocht je toch zoiets willen, gebruik dan de sig, daar is hij tenslotte voor...

P.p.s deze titel is niet echt informatief, ik pas'm aan (volgende keer zelf een relevanteren verzinnen )

[pt0x]

Om er maar niet omheen te draaien. Als jij zegt dat die berekening niet efficiënter kan worden gemaakt, en de uitslag is zo belangrijk is dat je er een laptop er al 14 uur voor laat werken dan zou je baas toch moeten overwegen om een snelle bak aan te schaffen voor deze berekening. In hoeverre je meer van deze berekeningen hebt weet ik niet. Maar een (of een paar) centrale rekenmonsters zijn toch wel wat goedkoper als bijv, 25 laptops x 2 (jullie hebben er 2 pp toch?)
Daarbij is zoals eerder gemeld Excel niet gericht op langdurige en moeilijke berekeningen.

Zolang je maar uitkijkt met calls en licenses van MS

[ Voor 8% gewijzigd door pt0x op 02-07-2004 09:27 ]

[Verwijderd]

Verwijderd schreef op 01 juli 2004 @ 16:20:
OK,

de bereking waar het in dit geval omgaat is een financieel model. Op basis van Monte Carlo simulation (voor degenen onder jullie die statistisch onderlegd zijn) die 10000 keer een bepaalde simulatie herhaalt, omzodoende een groot genoeg aantal simulaties te verkrijgen om een gemiddelde te kunnen bepalen dat betrouwbaar is.

Een enkele simulatie bestaat uit een model waarbij een zeer groot aantal aandelen die elk een dagelijkse volatiliteit hebben en ook nog eens alle 16 gecorreleerd zijn voor een aantal jaren voorspeld dienen te worden. Alleen hiervoor zijn er al zo'n honderdduizend berekeningen nodig, en dit dus nog x 10000. En helaas, dit kan niet efficienter......... Dan komt er nog wat Black & Scholes optiewaarderingbij etc. Voor degenen die statistisch en financieel weten waar ik het over heb: een behoorlijk model dus.

Ik las hierboven net een bericht dat je pas zou bij plaatsen als je 100 - 150 mb over hebt, waar kan ik dat zien? In task manager terwijl het model aan het draaien is?

Bedankt alvast voor de reacties so far.

Gr,

Joost

Ik ben zeker geen financieel expert, maar voor zover ik het me herinner van mijn lessen economie vroeger komen in dat soort modellen heel veel (diepgaande) recursieve berekeningen aan te pas. En laat ik nu ooit van iemand gehoord hebben dat Excel tot op de dag van vandaag absoluut niet efficient met recursieve dingen om kan gaan. Hij doet het, daar niet van, maar snel en efficient is wat anders.

En daardoor lijkt het me niet meer dan logisch dat jouw zwaar model, met zijn 10000 itteraties er 14u over doet. Moest je die berekening 'herschrijven' in een dedicated mathematisch programma, dan denk ik dat je mega tijdswinsten gaat boeken...

Just my 2 eurocents...

Off topic : zijn er hier mensen met zware wiskundige kennis die ervaring hebben met de inefficiente manier dat Excel berekeningen doet ? Die persoon van wie ik die opmerking ooit kreeg is zelfs zo ver gegaan dat hij er zelf voor leren programmeren heeft om zijn projecten en wiskundige modellen deftig snel te kunnen berekenen. HIj was ook ooit begonnen met die dingen in Excel op te bouwen, maar dat trok dus ook op niets. Sinds hij alles zelf maakt gebruikt hij Excel niet meer, maar in de begin periode heeft hij er wel opzoekingen over gedaan en toen beweerde hij dat de Excel engine zelfs bij triviale berekeningen fouten zou maken... Moest er iemand daar echte kennis van hebben, zo een discussie draadje zou ik met interesse volgen

[onkl]

Verwijderd schreef op 02 juli 2004 @ 13:17:
[...]
Off topic : zijn er hier mensen met zware wiskundige kennis die ervaring hebben met de inefficiente manier dat Excel berekeningen doet ? Die persoon van wie ik die opmerking ooit kreeg is zelfs zo ver gegaan dat hij er zelf voor leren programmeren heeft om zijn projecten en wiskundige modellen deftig snel te kunnen berekenen. HIj was ook ooit begonnen met die dingen in Excel op te bouwen, maar dat trok dus ook op niets. Sinds hij alles zelf maakt gebruikt hij Excel niet meer, maar in de begin periode heeft hij er wel opzoekingen over gedaan en toen beweerde hij dat de Excel engine zelfs bij triviale berekeningen fouten zou maken... Moest er iemand daar echte kennis van hebben, zo een discussie draadje zou ik met interesse volgen

Zo off-topic is dat geloof ik niet. Zonder zware wiskundige kennis waag ik een gokje:
1: Excel heeft een erg uitgebreide UI. Het gemiddelde "hard-core" wiskundige programma heeft een command- line interface (soms is iemand zo aardig geweest daar een GUI omheen te schrijven, maar dat doet hier nauwlijks terzake)
2: de hele structuur van Excel (ook de code neem ik stiekum aan) is gebaseerd op een tijdverdeling van zeg 99% invoerondersteunen (gelikte kunstjes laten zien als dropdown invoersuggesties en 1% hard rekenen.
3: De mathematische routines van Excel zijn relatief simplistisch, iig. vergeleken met dit soort geweld. Dat betekend dat iedere meer gecompliceerde berekening voor Excel geen "native" routine is, maar een combinatie en dus (uit principe) suboptimaal werkt.
4-veel: zal ook wel bestaan.

offtopic:
disclaimer, dit is een zo uit mijn mouw rollende educated guess, meer niet

Voor TS:
Kwam een leuke link tegen: Hier Niet heel bijzonder oid. maar geeft wel een beeld van de wereld.
(Er bestaat overigens een uiterst actieve Open Source gemeenschap rondom mathematische programmatuur. Wisselen meestal FORTRAN modules uit ed. Wel erg *nix gebaseerd, weet niet hoe je daarover denkt.) Interessant voor je baas: Het gemiddelde softwarepakket is beduidend goedkoper dan een GB laptopRAM

[TD-er]

De ervaring leert dat met zulke berekeningen er al een hoop aan snelheidswinst geboekt kan worden wanneer je de grootte van de data per rekenstap zo aanpast dat het in de cache van de processor past (kwestie van proberen, telkens verdubbelen/halveren totdat de performance ineens snel ander wordt)

Daarnaast kan het al heel veel schelen in snelheid wanneer je de data zodanig sorteert, dat het algoritme vaak (altijd) het volgende item nodig heeft en dus niet een semi-random item.

in sommige gevallen kan het snelheidsverschil wel oplopen tot een factor 100 of nog wel meer als je met bovenstaande dingen rekening houdt.

Maar goed gezien het feit dat de TS dit soort dingen in Excel uitvoert denk ik niet dat 'ie erg veel programmeer ervaring heeft en dan is het mischien handig naar pakketten als SPSS oid te kijken.

[CTVirus]

onkl schreef op 02 juli 2004 @ 14:04:
[...]

Zo off-topic is dat geloof ik niet. Zonder zware wiskundige kennis waag ik een gokje:
1: Excel heeft een erg uitgebreide UI. Het gemiddelde "hard-core" wiskundige programma heeft een command- line interface (soms is iemand zo aardig geweest daar een GUI omheen te schrijven, maar dat doet hier nauwlijks terzake)
2: de hele structuur van Excel (ook de code neem ik stiekum aan) is gebaseerd op een tijdverdeling van zeg 99% invoerondersteunen (gelikte kunstjes laten zien als dropdown invoersuggesties en 1% hard rekenen.
3: De mathematische routines van Excel zijn relatief simplistisch, iig. vergeleken met dit soort geweld. Dat betekend dat iedere meer gecompliceerde berekening voor Excel geen "native" routine is, maar een combinatie en dus (uit principe) suboptimaal werkt.
4-veel: zal ook wel bestaan.

offtopic:
disclaimer, dit is een zo uit mijn mouw rollende educated guess, meer niet

Voor TS:
Kwam een leuke link tegen: Hier Niet heel bijzonder oid. maar geeft wel een beeld van de wereld.
(Er bestaat overigens een uiterst actieve Open Source gemeenschap rondom mathematische programmatuur. Wisselen meestal FORTRAN modules uit ed. Wel erg *nix gebaseerd, weet niet hoe je daarover denkt.) Interessant voor je baas: Het gemiddelde softwarepakket is beduidend goedkoper dan een GB laptopRAM

Het feit dat een programma een mooie grafische shell heeft of op een bepaalde groep is gericht betekent nog niet dat het langzaam is. Het grootste probleem van excel is dat het een interpreter is, hierdoor is een snelheidswinst van ongeveer 10X zeker mogelijk als je het uitprogrameerd. Ik denk dat het kostefficienter voor een bedrijf is als ze vaak willen simuleren iets dergelijks uit te laten programeren dan het erg traag op hele dure servers te laten draaien.

[TD-er]

CTVirus schreef op 02 juli 2004 @ 14:44:
[...]


Het feit dat een programma een mooie grafische shell heeft of op een bepaalde groep is gericht betekent nog niet dat het langzaam is. Het grootste probleem van excel is dat het een interpreter is, hierdoor is een snelheidswinst van ongeveer 10X zeker mogelijk als je het uitprogrameerd. Ik denk dat het kostefficienter voor een bedrijf is als ze vaak willen simuleren iets dergelijks uit te laten programeren dan het erg traag op hele dure servers te laten draaien.

Klopt.
Een paar jaar geleden heb ik eens een grafisch filter uitgeprogrammeert in Java (moest voor een vak percee in Java) en met de 1.2 Java (zonder Just-in-time compiler) duurde het filter ~30 min en met de toen nieuwe Java 1.3.? met JIT duurde het amper 30 sec.

[Verwijderd]

TD-er schreef op 02 juli 2004 @ 14:40:
Daarnaast kan het al heel veel schelen in snelheid wanneer je de data zodanig sorteert, dat het algoritme vaak (altijd) het volgende item nodig heeft en dus niet een semi-random item.

Dit soort optimalisaties heb je echter geen vat op als je in programma's als Excel werkt. En AFAIK doet Excel dat zelf ook niet bepaald, met dus zulke gevolgen van dien.

Ik vrees dat TS ofwel ontiegelijk veel geld aan snellere hardware moet uitgeven, of zijn modellen in het vervolg met een alternatief (lees : meer geschikt) pakket moet opstellen...