Microsoft werkt aan multicoreoptimalisatie Excel

Microsofts Excel-productmanager David Gainer meldt op zijn weblog vooruitgang in het optimaliseren van Excel 12 voor multicoreprocessors. De resultaten zouden voldoende veelbelovend zijn om 'multi-threaded calculation', of kortweg MTC, als feature in Excel op te nemen. Multicoreprocessors kunnen berekeningen over meerdere processorcores uitsmeren; eerder riepen AMD en Microsoft de softwareindustrie op om te zorgen dat hun programmatuur deze mogelijkheid uit kan buiten.

De MTC-feature stelt Excel in staat om formules te herkennen die in onafhankelijke stukjes kunnen worden gehakt, dat wil zeggen stukjes waarvan er voor de berekening niet op andere berekeningen hoeft te worden gewacht. Volgens Gainer zijn de meeste Excel-sheets in de praktijk een mengeling van afhankelijke en onafhankelijke berekeningen, waardoor er in veel gevallen significante tijdwinst te boeken zou zijn. Er kunnen desgewenst meer threads worden ingesteld dan er cores op de machine aanwezig zijn; dit omdat Excel-toepassingen vaak berekeningen naar andere servers sturen. De feature is dan ook geen specifieke multicoreprocessor-feature maar een algemenere 'parallel processing'-feature. Voor Excel-ontwikkelaars zal MTC-functionaliteit beschikbaar zijn via XLL-functies. VBA als zodanig ondersteunt het niet; of VBA's opvolger VSTA wel direct multithreaded berekeningen zal ondersteunen is nog onduidelijk. Het Excel 12-team is op zoek naar bètatesters voor de MTC-functionaliteit; geïntereseerden kunnen via de bronpagina contact opnemen.

Reacties (41)

[Boss]

Nou, lekker hoor. Dan kunnen de snelle salesjongens lekker doorgaan met het misbruiken van Excel. Complete bedrijfsadministraties, polisadministraties en planningssystemen heb ik erin gezien (en dan nog van grote bedrijven ook), omdat men nooit de moeite heeft genomen om op zoek te gaan naar een fatsoenlijk dedicated softwarepakket. Ja, gek dat het traag wordt he. Vanaf een paar duizend regels trekt Excel het allemaal niet meer zo lekker (met een beperking op 65.536).

Onderhoudbaarheid van 0,0. Opgezet door 'handige medewerkers' zonder enig inzicht in hoe je op een structurele manier met gegevens om moet gaan. knip-en-plak werk, 10 lagen diep geneste functies, enorm veel dubbele invoer en opslag gegevens, fouten in cijfers omdat men er niet had aan gedacht dat formule maar tot regel 100 liep en regel 101 niet meepakt...

Gelukkig is Excel met deze update weer helemaal snel, zodat men lekker door kan gaan met trage oplossingen bouwen!

[darthdrinker]

HEARE HEARE!

Dit roep ik dus ook al jaren. Ik werk zelf bij een groot energie bedrijf, zelfs gedeeltes van de personeels administratie gebeuren hier in Excel!
Het is niet te geloven wat er allemaal nog meer op Excel gebied rondzwerft aan zogenaamde automatiserings oplossingen.VERSCHRIKKELIJK!

[Verwijderd]

Nouja, dedicated software pakket... meestal is Access gewoon "te moeilijk". Het valt niet mee om Microsoft Office volledig juist te gebruiken. Zelfs Word wordt vaak totaal verkeerd gebruikt. Tuurlijk, een briefje tikken moet lukken, maar efficiëntie is vaak ver te zoeken.

Maar Excel wordt vaak als database achtig iets gebruikt, en dat is het gewoon niet. Het is dan vaak beter om de boel in een Access database op te slaan, maar dat vereist ook de nodige kennis.

[Dreamvoid]

Maar dat is niet de fout van Excel, maar aan de mensen die het gebruiken. Laat je ze het in het in een "echte" database omgeving als SAP programmeren, dan moet je vervolgens hun crappy code gaan valideren en documenteren, en ben je niets opgeschoten tov Excel.

Overigens kan Excel wat optimalisaties heel goed gebruiken, zo is de TABLE functie baggertraag in vergelijking met software als Matlab. Ook RND is nou niet bepaald snel te noemen, en dat maakt Excel bv bijzonder onhandig voor Monte Carlo simulaties.

[edie]

Pakken ze dan ook de limiet van 65536 rijen aan?

[Verwijderd]

Als je in excel meer dan 65536 rijen nodig hebt, dan zou ik sterk adviseren dat in een dbase te steken denk dat dat nuttiger ga zijn dan

Als ik me nie vergis kunde die dbase dan met een connector aan u excel hangen, dan hebde meer dan 65536 rijen derin steken als ge percee niet van u excel af wil

[Quacka]

onzin.
Als je heel veel artikelen hebt van verschillende klanten, dan kan je best boven de 65000 regels uit komen, terwijl de berekeningen die je wilt doen echt niet zo ingewikkeld hoeven te zijn, dan het in access moet.

[praseodymium]

Uhm Access is een databasepakket en een databasepakket is niet bedoeld om te rekenen.

[BurningSheep]

Als je heel veel artikelen hebt van verschillende klanten, dan kan je best boven de 65000 regels uit komen, terwijl de berekeningen die je wilt doen echt niet zo ingewikkeld hoeven te zijn, dan het in excel moet.

gefixed.

[Rene59]

De nieuwe Excel 12 zal 1.048.576 rijen en 16.384 kolommen per werkblad hebben.

[edie]

Dat is een raar getal...

Ik zat eerder te denken aan 4.294.967.2956

[Verwijderd]

dat zou eens tijd worden. ik loop al jaren tegen die achterlijk 256 colommen aan.

De nieuwe Excel 12 zal 1.048.576 rijen en 16.384 kolommen per werkblad hebben

maar waarom nu weer de colommem beperken tov de rijen? Als je dan data wilt transposen(van vertikaal naar horozontaal, of omgekeerd) kan dat weer niet met je volledige diepte, maar met slechts (nu) 16.384.

Maargoed, elke uitbreiding is beter.

[familyman]

Wat een raar getal? Ik zou 45.360 kolommen verwachten
0-9 en A-Z is 36 waarden, drie tekens als kolom, de eerste kan geen nul zijn. (=35*36*36)

[Verwijderd]

kolommen in excel zijn nu ook a-z, verder dan aa, ab, ac etc. tot aan iv (256, 1 byte). Geen 0-9 in de kolommen.

26*26*26 = 17567. Dit zal men niet geheel vullen, maar de dichtsbij zijnde lagere macht van 2 nemen, namelijk: 2^14.

Tja, ik heb het ook niet bedacht...

[Verwijderd]

Waarom zouden ze? Kun je niet met "echte" databases omgaan? Zelfs met Access kun je vrij veel voor elkaar krijgen.

[TheSiemNL]

Mooi dat MS hier het voortouw in neemt. Wordt tijd dat andere softwareproducenten volgen en met "gratis" updates komen voor Dual Core optimalisaties.

[Verwijderd]

Ik vind het nogal kort door de bocht om te verwachten dat de inspanningen van softwaremakers gratis moeten zijn.

Software multi-threaded maken is binnen huidige ontwikkelomgevingen niet eenvoudig, omdat de gevolgen van eventele bugs op de kwaliteit van de software heel groot zijn (lees: veel bugs) en de code veel moeilijker te onderhouden worden.

Consumenten zullen een dergelijke verslechtering in kwaliteit niet accepteren, waardoor de investeringen in de benodigde aanpassingen moeilijk te verantwoorden zijn, zeker wanneer er niet een grote behoefte is aan betere performance en tegelijk de prijs niet mag toenemen.

[haling]

Dus andere bedrijven moeten het "gratis" doen en MS mag ~300 euro voor een nieuwe licentie vragen???

@Tijdbom: OK, je hebt me... een upgrade zal goedkoper zijn, maar Office is volgens mij wel errug vaak zonder licentie aanwezig op menig systeem... Zodra MS een actieve(/moeilijk(er) kraakbare) online activering op Office toe zal gaan passen en iedereen die bij de tijd wil blijven dus een nieuwe licentie moet kopen, zal wel ongeveer zoveel kwijt zijn...

[synthesix]

Ik zie hem dat niet zeggen noch zie ik in het artikel staan dat de update ~300 gaat kosten

[Conzales]

Zodra MS een actieve(/moeilijk(er) kraakbare) online activering op Office toe zal gaan passen..

offtopic:

Dan is het niet te hopen voor MS dat deze net zo makkelijk te kraken zal zijn als hun 'leuk bedachte' online 'windows genuine advantage' check. Die stelt ook niet veel voor.

Het is MS dan ook duidelijk niet te doen om al het illegaal gebruik buiten te sluiten, maar het doen laten lijken alsof ze er wel hard mee aan het werk zijn. Let wel, illegaal thuis-gebruik stimuleert tenslotte legaal gebruik bij bedrijven...

[Conzales]

Dat is toch ook precies mijn ironische stelling, of was dat niet duidelijk. Daarom staat de uitleg er nog onder ook!

[84hannes]

offtopic:
Het is voor microsoft WEL te hopen dat deze beveiliging net zo makkelijk te kraken is. Wat gebeurt er als alle consumenten massaal een prijs/kwaliteits analyse gaan doen bij de aanschaf van een nieuw officepakket? Leuk voor OpenOffice (en abiWord en GobeProductive), maar een ramp voor microsoft.

Volgens mij kan Acces ook wel wat winnen bij multicore, of zitten daar al stukjes mc software in?

[Verwijderd]

Als ze nou Acrobat Reader eens multithreaded zouden maken, das toch het enige programma wat mijn PC echt afremt.

Ik denk echter dat dat meer zegt over de kwaliteit van het programma als de 'zwaarheid' ervan.

[Jesse]

Of je installeerd gewoon de laatste versie van adobe reader (7), of gebruikt een speedup tooltje, dan is die lang zo baggertraag niet meer.

[golfdiesel]

speedup tooltjes zijn leuk, mits je alleen reader geinstalleerd hebt. Als je ook nog een volledige acrobat hebt ( ik gebruik de reader omdat die sneller is dan acrobat zelf) dan werkt die daarna niet goed meer.

[Tyf]

Idd, probeer maar eens Foxit Reader dan zul je zien dat een pdf reader echt niet zwaar hoeft te zijn

[10011]

Leuk detail hierbij is dat deze langzamer is dan de oplossing van adobe.

Niet zozeer het starten alswel het bekijken van pdfjes
en dit op een 3000+ amd.

[trogdor]

Het enige programma wat mijn PC echt afremt ?
Dan draai je zeker nooit Photosoep of zo.

[Verwijderd]

gewoon wachten op nieuwste office van Microsoft. Heb je geen adobe reader meer nodig!

[flossed]

multicore, multithreading, parralel processing. Nu kan een excel spreadsheet er tegelijkertijd op meerdere plekken uitknallen. ...

Maar zonder dollen, ik moet nog een spreadsheet tegenkomen die langzaam op een 386 kan draaien, leuk om MCP feature in te bouwen, maar een beetje overkill. Het heeft meer zin om MS WORD om te bouwen, zodat je tijdens het typen ook daadwerkelijk parallel grammar en spelling, en autosave functionaliteit kan toepassen. op een of andere manier heeft WORD veel meer capaciteit nodig van een PC dan een excell spreadsheet.

[Verwijderd]

maak je geen zorgen. Die spreadsheets zijn er ruim voldoende.
De huidige excel versies belasten je systeem al aardig zonder dat er een spreadsheet geopend is.

[rb338]

Ik heb bij Oracle gewerkt en daar wordt nog best veel met Excel gewerkt (ja je leest het goed ). De spreadsheets die daar voorkwamen konden ooit 50 MB groot zijn en als je daar een leuke pivot table (draaitabel) in gebruikt kan je nog best eens even bezig zijn.

Dat is nog maar een simpel voorbeeld. Ik kan me voorstellen dat je met VBA's (of dus VSTA) nog meer kracht kunt gebruiken. Daarnaast: als je toch een multicore cpu hebt, waarom er dan geen gebruik van maken

[Dreamvoid]

Je huishoudadministratie zal er idd niet veel mee opschieten, maar in het bedrijfsleven wordt Excel veel gebruikt en tot het uiterste belast. Vooral PivotTable, Conditional Formatting, TABLE, Solver, (V)LOOKUP en de random number generator zijn notoire performance killers. Om over plugins als Reuters PPP maar niet te spreken...

[sko]

Ik ben wel eens een spreadsheet tegengekomen die 45 min aan het doorrekenen was op een 2.4 GHz cpu (zware financieële analyses). Als dat multithreaded kan dan kan dat aardig wat tijdwinst opleveren..

[Verwijderd]

hey, vergeet je spreadsheet van 200 lijntjes eens.

Denk aan spreadsheets waarvan ALLE tabbladen volgestouwd zitten met data en formules.
Als ik op F9 duw (alle cellen herbereken, automatic calculation zet ik af of ik heb een grijze baard voor ik wat werk heb gedaan), kan ik gerust ondertussen mijn lunchpauze nemen voordat ie gedaan heeft.

Binnenkort gaan ze ook het aantal cellen verhogen: ipv 256 rijen -> 65536 rijen -> meer rekenkracht nodig.

Geloof me, die performance verbeterinen hebben echt wel nut.

[dev10]

Als je Gentoo installeerd en je zorgt ervoor dat de optimalisatie flags goed staan heb je Open Office 2 met Dual-Core ondersteuning. Goedkoper dan Office 12 die nog niet eens uit is.

[voodooless]

Compiler flag doen niks voor dual core hoor

[4VAlien]

Met flags blijft slechte code gewoon slechte code, wat er dus voor zorgt dat je slechte code x% sneller gaat, maar gewoon traag blijft. Een rewrite met een beter algoritme kan je niet vergelijken met het optimaliseren van wat lokale berekeningen.

[Database freak]

Maar zonder dollen, ik moet nog een spreadsheet tegenkomen die langzaam op een 386 kan draaien, leuk om MCP feature in te bouwen, maar een beetje overkill.

Maak in Excel maar eens een (OLAP) Pivottable obv 64000 regels met meerdere Vlookups in andere tabbladen en je 386 brand compleet af.

[familyman]

Volgens mij zijn de vlookups al niet eens nodig, daarvoor

[leuk_he]

Hyperthreading leverde dus blijkbaar niet genoeg voordeel op, want anders had men het toen wel eens geimplementeerd. Blijkbaar levert het pas echt wat op met dual code.