Search Results

Search found 8 results on 1 pages for 'grosser'.

Page 1/1 | 1 

  • Regex for splitting a german address into its parts

    - by Christian
    Good evening, I'm trying to splitting the parts of a german address string into its parts via Java. Does anyone know a regex or a library to do this? To split it like the following: Name der Straße 25a 88489 Teststadt to Name der Straße|25a|88489|Teststadt or Teststr. 3 88489 Beispielort (Großer Kreis) to Teststr.|3|88489|Beispielort (Großer Kreis) It would be perfect if the system / regex would still work if parts like the zip code or the city are missing. Is there any regex or library out there with which I could archive this? EDIT: Rule for german addresses: Street: Characters, numbers and spaces House no: Number and any characters (or space) until a series of numbers (zip) (at least in these examples) Zip: 5 digits Place or City: The rest maybe also with spaces, commas or braces

    Read the article

  • Flex/bison, error: undeclared

    - by Imran
    hallo, i have a problem, the followed program gives back an error, error:: Undeclared(first use in function), why this error appears all tokens are declared, but this error comes, can anyone help me, here are the lex and yac files.thanks lex: %{ int yylinenu= 1; int yycolno= 1; %} %x STR DIGIT [0-9] ALPHA [a-zA-Z] ID {ALPHA}(_?({ALPHA}|{DIGIT}))*_? GROUPED_NUMBER ({DIGIT}{1,3})(\.{DIGIT}{3})* SIMPLE_NUMBER {DIGIT}+ NUMMER {GROUPED_NUMBER}|{SIMPLE_NUMBER} %% <INITIAL>{ [\n] {++yylinenu ; yycolno=1;} [ ]+ {yycolno=yycolno+yyleng;} [\t]+ {yycolno=yycolno+(yyleng*8);} "*" {return MAL;} "+" {return PLUS;} "-" {return MINUS;} "/" {return SLASH;} "(" {return LINKEKLAMMER;} ")" {return RECHTEKLAMMER;} "{" {return LINKEGESCHWEIFTEKLAMMER;} "}" {return RECHTEGESCHEIFTEKLAMMER;} "=" {return GLEICH;} "==" {return GLEICHVERGLEICH;} "!=" {return UNGLEICH;} "<" {return KLEINER;} ">" {return GROSSER;} "<=" {return KLEINERGLEICH;} ">=" {return GROSSERGLEICH;} "while" {return WHILE;} "if" {return IF;} "else" {return ELSE;} "printf" {return PRINTF;} ";" {return SEMIKOLON;} \/\/[^\n]* { ;} {NUMMER} {return NUMBER;} {ID} {return IDENTIFIER;} \" {BEGIN(STR);} . {;} } <STR>{ \n {++yylinenu ;yycolno=1;} ([^\"\\]|"\\t"|"\\n"|"\\r"|"\\b"|"\\\"")+ {return STRING;} \" {BEGIN(INITIAL);} } %% yywrap() { } YACC: %{ #include stdio.h> #include string.h> #include "lex.yy.c" void yyerror(char *err); int error=0,linecnt=1; %} %token IDENTIFIER NUMBER STRING COMMENT PLUS MINUS MAL SLASH LINKEKLAMMER RECHTEKLAMMER LINKEGESCHWEIFTEKLAMMER RECHTEGESCHEIFTEKLAMMER GLEICH GLEICHVERGLEICH UNGLEICH GROSSER KLEINER GROSSERGLEICH KLEINERGLEICH IF ELSE WHILE PRINTF SEMIKOLON %start Stmts %% Stmts : Stmt {puts("\t\tStmts : Stmt");} |Stmt Stmts {puts("\t\tStmts : Stmt Stmts");} ; //NEUE REGEL---------------------------------------------- Stmt : LINKEGESCHWEIFTEKLAMMER Stmts RECHTEGESCHEIFTEKLAMMER {puts("\t\tStmt : '{' Stmts '}'");} |IF LINKEKLAMMER Cond RECHTEKLAMMER Stmt {puts("\t\tStmt : '(' Cond ')' Stmt");} |IF LINKEKLAMMER Cond RECHTEKLAMMER Stmt ELSE Stmt {puts("\t\tStmt : '(' Cond ')' Stmt 'ELSE' Stmt");} |WHILE LINKEKLAMMER Cond RECHTEKLAMMER Stmt {puts("\t\tStmt : 'PRINTF' Expr ';'");} |PRINTF Expr SEMIKOLON {puts("\t\tStmt : 'PRINTF' Expr ';'");} |IDENTIFIER GLEICH Expr SEMIKOLON {puts("\t\tStmt : 'IDENTIFIER' '=' Expr ';'");} |SEMIKOLON {puts("\t\tStmt : ';'");} ;//NEUE REGEL --------------------------------------------- Cond: Expr GLEICHVERGLEICH Expr {puts("\t\tCond : '==' Expr");} |Expr UNGLEICH Expr {puts("\t\tCond : '!=' Expr");} |Expr KLEINER Expr {puts("\t\tCond : '<' Expr");} |Expr KLEINERGLEICH Expr {puts("\t\tCond : '<=' Expr");} |Expr GROSSER Expr {puts("\t\tCond : '>' Expr");} |Expr GROSSERGLEICH Expr {puts("\t\tCond : '>=' Expr");} ;//NEUE REGEL -------------------------------------------- Expr:Term {puts("\t\tExpr : Term");} |Term PLUS Expr {puts("\t\tExpr : Term '+' Expr");} |Term MINUS Expr {puts("\t\tExpr : Term '-' Expr");} ;//NEUE REGEL -------------------------------------------- Term:Factor {puts("\t\tTerm : Factor");} |Factor MAL Term {puts("\t\tTerm : Factor '*' Term");} |Factor SLASH Term {puts("\t\tTerm : Factor '/' Term");} ;//NEUE REGEL -------------------------------------------- Factor:SimpleExpr {puts("\t\tFactor : SimpleExpr");} |MINUS SimpleExpr {puts("\t\tFactor : '-' SimpleExpr");} ;//NEUE REGEL -------------------------------------------- SimpleExpr:LINKEKLAMMER Expr RECHTEKLAMMER {puts("\t\tSimpleExpr : '(' Expr ')'");} |IDENTIFIER {puts("\t\tSimpleExpr : 'IDENTIFIER'");} |NUMBER {puts("\t\tSimpleExpr : 'NUMBER'");} |STRING {puts("\t\tSimpleExpr : 'String'");} ;//ENDE ------------------------------------------------- %% void yyerror(char *msg) { error=1; printf("Line: %d , Column: %d : %s \n", yylinenu, yycolno,yytext, msg); } int main(int argc, char *argv[]) { int val; while(yylex()) { printf("\n",yytext); } return yyparse(); }

    Read the article

  • Ausgezeichnet!

    - by A&C Redaktion
    Gute Nachrichten aus London: Oracle EMEA ist Vendor of the Year 2011 der European IT Excellence Awards! Der Preis wird von IT Europa verliehen, einem Unternehmen, das bekanntlich nicht nur als IT-Verlag, sondern auch in der Marktforschung zu den wichtigsten in Europa gehört. Was diese Auszeichnung für Oracle so bedeutend macht, ist jedoch etwas Anderes: Bei diesem Wettbewerb sind es die Partner, die entscheiden, ob ein Unternehmen überhaupt teilnehmen kann, da führt kein Weg dran vorbei. Es zählt also nicht nur die Entscheidung der in London tagenden Jury, bereits die Nominierung ist ein großer Vertrauensbeweis! Die Bewertungen unserer Partner zeigen: Oracle hat ein Channel-Programm entwickelt, das den Partnern hilft, höhere Profite zu erzielen und sich gegenüber der Konkurrenz deutlich abzusetzen. Stein Surlien, Senior Vice President, EMEA Alliances & Channel, ist stolz: „Das ist eine große Auszeichnung für Oracle. Sie zeigt, dass unsere Partner die Vorzüge und den Wert der Zusammenarbeit mit uns kennen und schätzen, und dass sich unsere spezifische Strategie auszahlt."

    Read the article

  • Datenbank in a Box

    - by A&C Redaktion
    Die Oracle Database Appliance: ein zuverlässiges, einfach zu bedienendes und erschwingliches Datenbank-System. Endlich kommt ein Datenbanksystem auf den Markt, das auf die Bedürfnisse kleinerer Unternehmen zugeschnitten ist: Oracle Database Appliance (ODA). Nicht jeder, der große Datenmengen zu verwalten hat, kann schließlich gleich zu Exadata und Co. greifen. Die kompakte „Datenbank in a Box“ kombiniert Software, Server und Speicherkapazität und bietet diverse Vernetzungsmöglichkeiten. Sie beinhaltet zwei geclusterte SunFire-Server, die unter Oracle Linux laufen, vorinstalliert ist eine Oracle Database 11g Release 2. Einer der großen ODA-Vorteile: Die Datenbank wächst mit den Bedürfnissen des Unternehmens: Die Leistungsfähigkeit des Clusters lässt sich anpassen, indem per "Pay-as-you-grow" Software-Lizensierung sukzessive zwei bis 24 Cores freigeschaltet werden können. Sie bietet außerdem hohe Verfügbarkeit für Eigen- und Standard-OLTP sowie universelle Datenbanken, auch in großer Anzahl. Für den Schutz vor Server- und Speichersystemausfällen sorgen Oracle Real Application Clusters, beziehungsweise Oracle Automatic Storage Management. Proaktive Systemüberwachung, Software-Bereitstellung auf einen Klick, integrierte Patches über den gesamten Stack und ein automatischer Call-Home bei Hardware-Ausfällen sparen Kosten und Ressourcen bei der Instandhaltung. Über das Oracle PartnerNetzwerk steht Kunden eine große Anzahl an branchenübergreifenden und -spezifischen Anwendungen zur Verfügung, die von der besseren Verfügbarkeit der Oracle Database Appliance profitieren. Auch die Fachpresse setzt sich mit der neuen Oracle Database Appliance auseinander: Ausführlich berichten unter anderem die Computerwoche und heise online. Das Admin-Magazin bietet eine kurze aber treffende Übersicht. Eine ebenfalls anschauliche, etwas ausführlichere Darstellung bietet die Webseite von DOAG e.V. Im Webcast zur Oracle Database Appliance geht Judson Althoff unter anderem auf deren Bedeutung für das Partner-Business ein:

    Read the article

  • How to set up RPX widget and facebook app to be able to authenticate with rpx_now?

    - by Andrei
    Using the sample app for rpx_now gem ( http://github.com/grosser/rpx_now_example) on localhost:3000, I have successfully logged in via Google Accounts, myOpenID, Yahoo, but cannot make it via Facebook. In the RPX app/widget settings I have set my facebook-app key and secret. In my facebook app settings, the Connect URL is myappname.rpxnow.com. But when I try to connect, then I don't even see a facebook login page, just a number of redirects and I am back to my localhost with the following exception http://gist.github.com/386520 . Before I was successfully connecting with oauth2 gem, however, without fetching user data - only authentication. That time I set only key/secret and localhost as my Connect URL. Currently, I don't even ask for email etc., but still the same problem. Can it happen because rpx_now cannot get requested user data from facebook? Or it is a problem of facebook key/secret? May be I need to provide more settings of my facebook app? RPXNow::ApiError in UsersController#create Got error: Invalid parameter: token (code: 1), HTTP status: 200 RAILS_ROOT: /home/Andrei/rpx_now_example Application Trace | Framework Trace | Full Trace /usr/lib/ruby/gems/1.8/gems/rpx_now-0.6.20/lib/rpx_now/api.rb:71:in `parse_response' /usr/lib/ruby/gems/1.8/gems/rpx_now-0.6.20/lib/rpx_now/api.rb:21:in `call' /usr/lib/ruby/gems/1.8/gems/rpx_now-0.6.20/lib/rpx_now.rb:23:in `user_data' /home/Andrei/rpx_now_example/app/controllers/users_controller.rb:16:in `create' Request Parameters: None Show session dump Response Headers: {"Content-Type"="", "Cache-Control"="no-cache"}

    Read the article

  • LINQ und ArcObjects

    - by Marko Apfel
    LINQ und ArcObjects Motivation LINQ1 (language integrated query) ist eine Komponente des Microsoft .NET Frameworks seit der Version 3.5. Es erlaubt eine SQL-ähnliche Abfrage zu verschiedenen Datenquellen wie SQL, XML u.v.m. Wie SQL auch, bietet LINQ dazu eine deklarative Notation der Problemlösung - d.h. man muss nicht im Detail beschreiben wie eine Aufgabe, sondern was überhaupt zu lösen ist. Das befreit den Entwickler abfrageseitig von fehleranfälligen Iterator-Konstrukten. Ideal wäre es natürlich auf diese Möglichkeiten auch in der ArcObjects-Programmierung mit Features zugreifen zu können. Denkbar wäre dann folgendes Konstrukt: var largeFeatures = from feature in features where (feature.GetValue("SHAPE_Area").ToDouble() > 3000) select feature; bzw. dessen Äquivalent als Lambda-Expression: var largeFeatures = features.Where(feature => (feature.GetValue("SHAPE_Area").ToDouble() > 3000)); Dazu muss ein entsprechender Provider zu Verfügung stehen, der die entsprechende Iterator-Logik managt. Dies ist leichter als man auf den ersten Blick denkt - man muss nur die gewünschten Entitäten als IEnumerable<IFeature> liefern. (Anm.: nicht wundern - die Methoden GetValue() und ToDouble() habe ich nebenbei als Erweiterungsmethoden deklariert.) Im Hintergrund baut LINQ selbständig eine Zustandsmaschine (state machine)2 auf deren Ausführung verzögert ist (deferred execution)3 - d.h. dass erst beim tatsächlichen Anfordern von Entitäten (foreach, Count(), ToList(), ..) eine Instanziierung und Verarbeitung stattfindet, obwohl die Zuweisung schon an ganz anderer Stelle erfolgte. Insbesondere bei mehrfacher Iteration durch die Entitäten reibt man sich bei den ersten Debuggings verwundert die Augen wenn der Ausführungszeiger wie von Geisterhand wieder in die Iterator-Logik springt. Realisierung Eine ganz knappe Logik zum Konstruieren von IEnumerable<IFeature> lässt sich mittels Durchlaufen eines IFeatureCursor realisieren. Dazu werden die einzelnen Feature mit yield ausgegeben. Der einfachen Verwendung wegen, habe ich die Logik in eine Erweiterungsmethode GetFeatures() für IFeatureClass aufgenommen: public static IEnumerable GetFeatures(this IFeatureClass featureClass, IQueryFilter queryFilter, RecyclingPolicy policy) { IFeatureCursor featureCursor = featureClass.Search(queryFilter, RecyclingPolicy.Recycle == policy); IFeature feature; while (null != (feature = featureCursor.NextFeature())) { yield return feature; } //this is skipped in unit tests with cursor-mock if (Marshal.IsComObject(featureCursor)) { Marshal.ReleaseComObject(featureCursor); } } Damit kann man sich nun ganz einfach die IEnumerable<IFeature> erzeugen lassen: IEnumerable features = _featureClass.GetFeatures(RecyclingPolicy.DoNotRecycle); Etwas aufpassen muss man bei der Verwendung des "Recycling-Cursors". Nach einer verzögerten Ausführung darf im selben Kontext nicht erneut über die Features iteriert werden. In diesem Fall wird nämlich nur noch der Inhalt des letzten (recycelten) Features geliefert und alle Features sind innerhalb der Menge gleich. Kritisch würde daher das Konstrukt largeFeatures.ToList(). ForEach(feature => Debug.WriteLine(feature.OID)); weil ToList() schon einmal durch die Liste iteriert und der Cursor somit einmal durch die Features bewegt wurde. Die Erweiterungsmethode ForEach liefert dann immer dasselbe Feature. In derartigen Situationen darf also kein Cursor mit Recycling verwendet werden. Ein mehrfaches Ausführen von foreach ist hingegen kein Problem weil dafür jedes Mal die Zustandsmaschine neu instanziiert wird und somit der Cursor neu durchlaufen wird – das ist die oben schon erwähnte Magie. Ausblick Nun kann man auch einen Schritt weiter gehen und ganz eigene Implementierungen für die Schnittstelle IEnumerable<IFeature> in Angriff nehmen. Dazu müssen nur die Methode und das Property zum Zugriff auf den Enumerator ausprogrammiert werden. Im Enumerator selbst veranlasst man in der Reset()-Methode das erneute Ausführen der Suche – dazu übergibt man beispielsweise ein entsprechendes Delegate in den Konstruktur: new FeatureEnumerator( _featureClass, featureClass => featureClass.Search(_filter, isRecyclingCursor)); und ruft dieses beim Reset auf: public void Reset() {     _featureCursor = _resetCursor(_t); } Auf diese Art und Weise können Enumeratoren für völlig verschiedene Szenarien implementiert werden, die clientseitig restlos identisch nach obigen Schema verwendet werden. Damit verschmelzen Cursors, SelectionSets u.s.w. zu einer einzigen Materie und die Wiederverwendbarkeit von Code steigt immens. Obendrein lässt sich ein IEnumerable in automatisierten Unit-Tests sehr einfach mocken - ein großer Schritt in Richtung höherer Software-Qualität.4 Fazit Nichtsdestotrotz ist Vorsicht mit diesen Konstrukten in performance-relevante Abfragen geboten. Dadurch dass im Hintergrund eine Zustandsmaschine verwalten wird, entsteht einiges an Overhead dessen Verarbeitung zusätzliche Zeit kostet - ca. 20 bis 100 Prozent. Darüber hinaus ist auch das Arbeiten ohne Recycling schnell ein Performance-Gap. Allerdings ist deklarativer LINQ-Code viel eleganter, fehlerfreier und wartungsfreundlicher als das manuelle Iterieren, Vergleichen und Aufbauen einer Ergebnisliste. Der Code-Umfang verringert sich erfahrungsgemäß im Schnitt um 75 bis 90 Prozent! Dafür warte ich gerne ein paar Millisekunden länger. Wie so oft muss abgewogen werden zwischen Wartbarkeit und Performance - wobei für mich Wartbarkeit zunehmend an Priorität gewinnt. Zumeist ist sowieso nicht der Code sondern der Anwender die Bremse im Prozess. Demo-Quellcode support.esri.de   [1] Wikipedia: LINQ http://de.wikipedia.org/wiki/LINQ [2] Wikipedia: Zustandsmaschine http://de.wikipedia.org/wiki/Endlicher_Automat [3] Charlie Calverts Blog: LINQ and Deferred Execution http://blogs.msdn.com/b/charlie/archive/2007/12/09/deferred-execution.aspx [4] Clean Code Developer - gelber Grad/Automatisierte Unit Tests http://www.clean-code-developer.de/Gelber-Grad.ashx#Automatisierte_Unit_Tests_8

    Read the article

  • Das T5-4 TPC-H Ergebnis naeher betrachtet

    - by Stefan Hinker
    Inzwischen haben vermutlich viele das neue TPC-H Ergebnis der SPARC T5-4 gesehen, das am 7. Juni bei der TPC eingereicht wurde.  Die wesentlichen Punkte dieses Benchmarks wurden wie gewohnt bereits von unserer Benchmark-Truppe auf  "BestPerf" zusammengefasst.  Es gibt aber noch einiges mehr, das eine naehere Betrachtung lohnt. Skalierbarkeit Das TPC raet von einem Vergleich von TPC-H Ergebnissen in unterschiedlichen Groessenklassen ab.  Aber auch innerhalb der 3000GB-Klasse ist es interessant: SPARC T4-4 mit 4 CPUs (32 Cores mit 3.0 GHz) liefert 205,792 QphH. SPARC T5-4 mit 4 CPUs (64 Cores mit 3.6 GHz) liefert 409,721 QphH. Das heisst, es fehlen lediglich 1863 QphH oder 0.45% zu 100% Skalierbarkeit, wenn man davon ausgeht, dass die doppelte Anzahl Kerne das doppelte Ergebnis liefern sollte.  Etwas anspruchsvoller, koennte man natuerlich auch einen Faktor von 2.4 erwarten, wenn man die hoehere Taktrate mit beruecksichtigt.  Das wuerde die Latte auf 493901 QphH legen.  Dann waere die SPARC T5-4 bei 83%.  Damit stellt sich die Frage: Was hat hier nicht skaliert?  Vermutlich der Plattenspeicher!  Auch hier lohnt sich eine naehere Betrachtung: Plattenspeicher Im Bericht auf BestPerf und auch im Full Disclosure Report der TPC stehen einige interessante Details zum Plattenspeicher und der Konfiguration.   In der Konfiguration der SPARC T4-4 wurden 12 2540-M2 Arrays verwendet, die jeweils ca. 1.5 GB/s Durchsatz liefert, insgesamt also eta 18 GB/s.  Dabei waren die Arrays offensichtlich mit jeweils 2 Kabeln pro Array direkt an die 24 8GBit FC-Ports des Servers angeschlossen.  Mit den 2x 8GBit Ports pro Array koennte man so ein theoretisches Maximum von 2GB/s erreichen.  Tatsaechlich wurden 1.5GB/s geliefert, was so ziemlich dem realistischen Maximum entsprechen duerfte. Fuer den Lauf mit der SPARC T5-4 wurden doppelt so viele Platten verwendet.  Dafuer wurden die 2540-M2 Arrays mit je einem zusaetzlichen Plattentray erweitert.  Mit dieser Konfiguration wurde dann (laut BestPerf) ein Maximaldurchsatz von 33 GB/s erreicht - nicht ganz das doppelte des SPARC T4-4 Laufs.  Um tatsaechlich den doppelten Durchsatz (36 GB/s) zu liefern, haette jedes der 12 Arrays 3 GB/s ueber seine 4 8GBit Ports liefern muessen.  Im FDR stehen nur 12 dual-port FC HBAs, was die Verwendung der Brocade FC Switches erklaert: Es wurden alle 4 8GBit ports jedes Arrays an die Switches angeschlossen, die die Datenstroeme dann in die 24 16GBit HBA ports des Servers buendelten.  Das theoretische Maximum jedes Storage-Arrays waere nun 4 GB/s.  Wenn man jedoch den Protokoll- und "Realitaets"-Overhead mit einrechnet, sind die tatsaechlich gelieferten 2.75 GB/s gar nicht schlecht.  Mit diesen Zahlen im Hinterkopf ist die Verdopplung des SPARC T4-4 Ergebnisses eine gute Leistung - und gleichzeitig eine gute Erklaerung, warum nicht bis zum 2.4-fachen skaliert wurde. Nebenbei bemerkt: Weder die SPARC T4-4 noch die SPARC T5-4 hatten in der gemessenen Konfiguration irgendwelche Flash-Devices. Mitbewerb Seit die T4 Systeme auf dem Markt sind, bemuehen sich unsere Mitbewerber redlich darum, ueberall den Eindruck zu hinterlassen, die Leistung des SPARC CPU-Kerns waere weiterhin mangelhaft.  Auch scheinen sie ueberzeugt zu sein, dass (ueber)grosse Caches und hohe Taktraten die einzigen Schluessel zu echter Server Performance seien.  Wenn ich mir nun jedoch die oeffentlichen TPC-H Ergebnisse ansehe, sehe ich dies: TPC-H @3000GB, Non-Clustered Systems System QphH SPARC T5-4 3.6 GHz SPARC T5 4/64 – 2048 GB 409,721.8 SPARC T4-4 3.0 GHz SPARC T4 4/32 – 1024 GB 205,792.0 IBM Power 780 4.1 GHz POWER7 8/32 – 1024 GB 192,001.1 HP ProLiant DL980 G7 2.27 GHz Intel Xeon X7560 8/64 – 512 GB 162,601.7 Kurz zusammengefasst: Mit 32 Kernen (mit 3 GHz und 4MB L3 Cache), liefert die SPARC T4-4 mehr QphH@3000GB ab als IBM mit ihrer 32 Kern Power7 (bei 4.1 GHz und 32MB L3 Cache) und auch mehr als HP mit einem 64 Kern Intel Xeon System (2.27 GHz und 24MB L3 Cache).  Ich frage mich, wo genau SPARC hier mangelhaft ist? Nun koennte man natuerlich argumentieren, dass beide Ergebnisse nicht gerade neu sind.  Nun, in Ermangelung neuerer Ergebnisse kann man ja mal ein wenig spekulieren: IBMs aktueller Performance Report listet die o.g. IBM Power 780 mit einem rPerf Wert von 425.5.  Ein passendes Nachfolgesystem mit Power7+ CPUs waere die Power 780+ mit 64 Kernen, verfuegbar mit 3.72 GHz.  Sie wird mit einem rPerf Wert von  690.1 angegeben, also 1.62x mehr.  Wenn man also annimmt, dass Plattenspeicher nicht der limitierende Faktor ist (IBM hat mit 177 SSDs getestet, sie duerfen das gerne auf 400 erhoehen) und IBMs eigene Leistungsabschaetzung zugrunde legt, darf man ein theoretisches Ergebnis von 311398 QphH@3000GB erwarten.  Das waere dann allerdings immer noch weit von dem Ergebnis der SPARC T5-4 entfernt, und gerade in der von IBM so geschaetzen "per core" Metric noch weniger vorteilhaft. In der x86-Welt sieht es nicht besser aus.  Leider gibt es von Intel keine so praktischen rPerf-Tabellen.  Daher muss ich hier fuer eine Schaetzung auf SPECint_rate2006 zurueckgreifen.  (Ich bin kein grosser Fan von solchen Kreuz- und Querschaetzungen.  Insb. SPECcpu ist nicht besonders geeignet, um Datenbank-Leistung abzuschaetzen, da fast kein IO im Spiel ist.)  Das o.g. HP System wird bei SPEC mit 1580 CINT2006_rate gelistet.  Das bis einschl. 2013-06-14 beste Resultat fuer den neuen Intel Xeon E7-4870 mit 8 CPUs ist 2180 CINT2006_rate.  Das ist immerhin 1.38x besser.  (Wenn man nur die Taktrate beruecksichtigen wuerde, waere man bei 1.32x.)  Hier weiter zu rechnen, ist muessig, aber fuer die ungeduldigen Leser hier eine kleine tabellarische Zusammenfassung: TPC-H @3000GB Performance Spekulationen System QphH* Verbesserung gegenueber der frueheren Generation SPARC T4-4 32 cores SPARC T4 205,792 2x SPARC T5-464 cores SPARC T5 409,721 IBM Power 780 32 cores Power7 192,001 1.62x IBM Power 780+ 64 cores Power7+  311,398* HP ProLiant DL980 G764 cores Intel Xeon X7560 162,601 1.38x HP ProLiant DL980 G780 cores Intel Xeon E7-4870    224,348* * Keine echten Resultate  - spekulative Werte auf der Grundlage von rPerf (Power7+) oder SPECint_rate2006 (HP) Natuerlich sind IBM oder HP herzlich eingeladen, diese Werte zu widerlegen.  Aber stand heute warte ich noch auf aktuelle Benchmark Veroffentlichungen in diesem Datensegment. Was koennen wir also zusammenfassen? Es gibt einige Hinweise, dass der Plattenspeicher der begrenzende Faktor war, der die SPARC T5-4 daran hinderte, auf jenseits von 2x zu skalieren Der Mythos, dass SPARC Kerne keine Leistung bringen, ist genau das - ein Mythos.  Wie sieht es umgekehrt eigentlich mit einem TPC-H Ergebnis fuer die Power7+ aus? Cache ist nicht der magische Performance-Schalter, fuer den ihn manche Leute offenbar halten. Ein System, eine CPU-Architektur und ein Betriebsystem jenseits einer gewissen Grenze zu skalieren ist schwer.  In der x86-Welt scheint es noch ein wenig schwerer zu sein. Was fehlt?  Nun, das Thema Preis/Leistung ueberlasse ich gerne den Verkaeufern ;-) Und zu guter Letzt: Nein, ich habe mich nicht ins Marketing versetzen lassen.  Aber manchmal kann ich mich einfach nicht zurueckhalten... Disclosure Statements The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. TPC-H, QphH, $/QphH are trademarks of Transaction Processing Performance Council (TPC). For more information, see www.tpc.org, results as of 6/7/13. Prices are in USD. SPARC T5-4 409,721.8 QphH@3000GB, $3.94/QphH@3000GB, available 9/24/13, 4 processors, 64 cores, 512 threads; SPARC T4-4 205,792.0 QphH@3000GB, $4.10/QphH@3000GB, available 5/31/12, 4 processors, 32 cores, 256 threads; IBM Power 780 QphH@3000GB, 192,001.1 QphH@3000GB, $6.37/QphH@3000GB, available 11/30/11, 8 processors, 32 cores, 128 threads; HP ProLiant DL980 G7 162,601.7 QphH@3000GB, $2.68/QphH@3000GB available 10/13/10, 8 processors, 64 cores, 128 threads. SPEC and the benchmark names SPECfp and SPECint are registered trademarks of the Standard Performance Evaluation Corporation. Results as of June 18, 2013 from www.spec.org. HP ProLiant DL980 G7 (2.27 GHz, Intel Xeon X7560): 1580 SPECint_rate2006; HP ProLiant DL980 G7 (2.4 GHz, Intel Xeon E7-4870): 2180 SPECint_rate2006,

    Read the article

1