Hilfe 1*1 !

[derdon]

Immerhin runter auf 81:

Code: Alles auswählen

1:i;{i 10>}{1:j;{j 11<}{j' x 'i' = 'i j*++++puts j):j;}while n print i):i;}until

[BlackJack]

@Hyperion: Naja, eigentlich zählt ja die Quelltextgrösse und da ist das Assemblerprogramm viel zu gross um Konkurrenzfähig zu sein.

Das übersetze Assembler-Programm ist 75 Bytes gross (73 Bytes Code + 2 Bytes Startadresse).

Und wenn man die Dateigrösse als Grundlage nimmt, dann ist Dein BASIC-Programm nur 43 Bytes gross, wenn ich mich nicht verzählt habe. Die BASIC-Schlüsselwörter werden jeweils in nur einem Byte gespeichert. Plus Startadresse, 2 Byte-Zeilennummer, 2 Byte Pointer auf den Anfang der nächsten Zeile, Nullbyte zum Abschluss der Zeile und zwei Nullbyte die das Ende des Programms markieren (darauf zeigt der "Nächste-Zeile"-Pointer).

Bei dem BASIC bekommt man den Quelltext selbst aber sogar unter die Dateigrösse, weil man die meisten Befehle bei der Eingabe mit zwei Zeichen abkürzen kann. ``PRINT`` sogar mit einem ``?``:

Code: Alles auswählen

0fOa=1to10:fOb=1to10:?b"x"a"="a*b:nE:?:nE

[lunar]

Ich hätte noch (SWI-)Prolog zu bieten:

Code: Alles auswählen

timestable(X,Y,XY) :- between(1, 10, Y), between(1, 10, X), XY is X*Y.

writetimestable :-
    forall(timestable(X,Y,XY), writef("%3r * %3r = %3r\n", [X, Y, XY])).

[b.esser-wisser]

Das 'Problem' kann man doch parallelisieren:

Code: Alles auswählen

#include <stdlib.h>
#include <stdio.h>
#include <omp.h>

#define MAX 10
int main(void)
{
    puts("Das Einmaleins");
    for(int i=1; i <= MAX; ++i) {
        int result;
#pragma omp parallel for private (result)
        for(int j=1; j <= MAX; ++j) {
            result = i*j;
#pragma omp critical
            {
                printf("%d x %d = %d\n", i, j, result);
            }
        }
    }
    return EXIT_SUCCESS;
}

Ich wollte bloß wissen, ob mein mingw32 opemMP unterstützt (ja, mit dem Parameter '-fopenmp') -und die Ausgabe sieht nicht genau aus wie gefordert

[Hyperion]

lol Nice!

Interessant wäre es zu bestimmen, ob bzw. ab welchem Wert von MAX es sich lohnt Bei einer simplen Multiplikation wird man da wohl erst weit nach der Integer Grenze einen Benefit spüren...

[b.esser-wisser]

Damit sich das lohnt, muss man entweder das 'printf()' parallelisieren (?!) oder Berechnung und Ausgabe trennen.
Ich find nur geil, wie (relativ) wenig Programmierer-Aufwand das parallelisieren hier ist.

[lunar]

@b.esser-wisser: Man könnte "result" sinnvollerweise erst in der inneren Schleife deklarieren, dass erspart die "private"-Klausel.

[BlackJack]

In Python ist das Parallelisieren ja auch kein grosser Programmieraufwand:

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-
from multiprocessing import Pool


def f(n):
    return '\n'.join('%d × %d = %d' % (i, n, i * n) for i in xrange(11))


def main():
    print '\n\n'.join(Pool().map(f, range(11)))


if __name__ == '__main__':
    main()

[Hyperion]

In Python ist das Parallelisieren ja auch kein grosser Programmieraufwand:

Gibt es da eigentlich eine gute Beschreibung, inwiefern das etwas bringt? Ich habe immer mir unverständliches bezüglich des GILs gelesen, aus dem ich mitnahm, dass Parallelisieren in Python quasi nix bringt. Würde mich mal interessieren, da etwas fundiertes, aber für mich verständliches zu lesen

[BlackJack]

@Hyperion: Eine gute Beschreibung wüsste ich jetzt auch nicht, aber das GIL ist doch recht simpel erklärt: Python-Bytecode wird in CPython immer nur von einem Thread gleichzeitig ausgeführt. Und alle `n` Bytecodes wird das GIL potentiell einem anderen Thread übertragen. Zum Abfragen und Festlegen von `n` gibt es `sys.[gs]etcheckintervall()`. Wenn man in CPython also mit Threads parallelisieren will, kann immer nur ein Thread Bytecode ausführen. Blockierende IO-Funktionen geben das GIL vor Ablauf der `n` Bytecodes frei und in C implementierte Funktionen können das GIL auch aufgeben und damit tatsächlich parallel zu Bytecode oder anderen C-Funktionen laufen.

Bei `multiprocessing` werden mehrere Prozesse gestartet und die können dann auch Bytecode parallel ausführen. Mit dem Nachteil, das die Argumente und Ergebnisse über Prozessgrenzen hinweg übermittelt werden müssen.

[Hyperion]

Blockierende IO-Funktionen geben das GIL vor Ablauf der `n` Bytecodes frei und in C implementierte Funktionen können das GIL auch aufgeben und damit tatsächlich parallel zu Bytecode oder anderen C-Funktionen laufen.

Ah, ok. Das beudetet also, dass wenn eine Funktion den GIL nicht vorher freigibt, eine Parallelisierung keinen Benefit gibt, richtig?

Bei `multiprocessing` werden mehrere Prozesse gestartet und die können dann auch Bytecode parallel ausführen. Mit dem Nachteil, das die Argumente und Ergebnisse über Prozessgrenzen hinweg übermittelt werden müssen.

Das kostet vermutlich deutlich mehr Rechenzeit und verbraucht auch mehr Ressourcen generell, oder? Würde also eher bei solchen Prozessen sinnvoll sein, die eine große Datenmenge separat bearbeiten können oder auch nicht ständig sich mit anderen Threads austauschen müssen.

[BlackJack]

@Hyperion: Zur ersten Frage: Wenn das GIL nicht freigegeben wird, dann findet effektiv ja keine Parallelisierung statt.

Und ja, `multiprocessing` bringt am meisten wenn die Teilaufgaben möglichst unabhängig sind und wenig direkten Datenaustausch untereinander erfordern.

[b.esser-wisser]

'multiprocessing' started zusätzliche Interpreter*, da gibt's dann entsprechend mehrere GILs, 'threading' nutzt nur einen interpreter, einen GIL und AFAIK nur einen Prozessor(-kern).
Aber ohne threading hat man auch kaum einen/keinen Vorteil von C-Funktionen, die den GIL freigeben.

* Deshalb ist unter Windows dann die 'if __name__ == "__main__"' notwendig, s. docs

[Hyperion]

Da frage ich mich doch mal, wie das dann andere Maschinen, z.B. die JVM lösen? Und bei Jython dürfte es dann ja eigentlich leichter sein, mittels threading Performance zu gewinnen, da die JVM ja keinen GIL kennt.

Ich seh schon wieder die Diskussion abgleiten vom Thema - ok, den OP haben wir eh verschreckt oder durch die Antworten auf Seite eins eine Lösung für die Schule gegeben

[BlackJack]

@b.esser-wisser: Bei CPython's `threading` werden ganz normale Threads verwendet, die laufen also grundsätzlich auch parallel und auf allen Prozessoren/Kernen. Nur eben durch das GIL Bytecode immer nur in einem Thread zu einer gegebenen Zeit. Wenn man mehrere Threads zum Beispiel mit `numpy`-Aufrufen hat, die das GIL freigeben, dann laufen diese Operationen potentiell auch parallel auf mehreren Prozessoren/Kernen.

@Hyperion: Das GIL gibt es in CPython weil man sonst für jedes Objekt für den Referenzzähler ein Lock bräuchte und bei jedem Verändern des Referenzzählers -- und das passiert ja im Grunde bei jeder Übergabe des Objekts als Argument -- diese Veränderung durch das Lock schützen müsste. Das wurde wohl auch mal probiert, aber das Ergebnis war deutlich langsamer als CPython mit GIL. Und Guido hat sinngemäss angesagt "GIL abschaffen ist okay -- aber es darf dadurch im normalen Ein-Thread-Fall nicht langsamer werden".

Bei Java gibt es kein GIL, weil die Speicherbereinigung da nicht mit Referenzzählern arbeitet. Die Speichervewaltung benötigt dafür mehr Speicher und gibt den Speicher für die meisten Objekte nicht so "zeitnah" wieder frei wie CPython.

[b.esser-wisser]

Okay, Python ist nicht an eine CPU gebunden (Wenn ich drüber nachdenke, wieso sollte es?) - ein simples Testprogramm wechselt bei mir zwischen den zwei Kernen hin und her.

Noch offtopic'er: weil threads unter Java so viel nützlicher sind hat Sun ja sowas entwickelt: mit 8x8 Threads in Hardware

[Rebecca]

Okay, Python ist nicht an eine CPU gebunden (Wenn ich drüber nachdenke, wieso sollte es?) - ein simples Testprogramm wechselt bei mir zwischen den zwei Kernen hin und her.

Das ist wahrscheinlich dein Betriebssystem, dass versucht, die Prozessoren gleichmaessig auszulasten wg. der Hitze. Trotzdem benutzt Python nur einen Kern gleichzeitig, und darum geht es hier ja.

[b.esser-wisser]

@Rebecca: nur ein Kern auf einmal war klar -- mir war nicht klar, dass trotzdem mehrere Kerne genutzt werden (z.B. sind dann einige Stromspar-mechanismen dahin)

[Rebecca]

Was den fuer Stromspar-Mechanismen? Ich war immer davon ausgegangen, dass die Kerne wegen der Waerme gewechselt werden, damit weniger gelueftet werden muss. Das spart schon Strom.

[lunar]

@b.esser-wisser: Dieser Frage schließe ich mich an: Welche Stromsparmechanismen meinst Du? Ich glaube nämlich nicht, dass da tatsächlich irgendetwas „dahin“ ist.