От Александр
К Iva
Дата 21.08.2009 22:08:19
Рубрики Россия-СССР; Крах СССР; История; Идеология;

Сразу видно что товарищ не только компиляторов не писал,

>Только практическая разница существенна 50 строк фортрана - это 1500-5000 строк асемблера.

но даже не полюбопытствовал скомпилировать програмку в язык ассемблера, где исходный текст в виде комментариев, да посмотреть во сколько ассемблерных команд на самом деле компилируется строка языка высокого уровня. 3-4. Особенно если речь о фортране. Пожалуй единственное исключение - арифметические выражения и вызовы фунцкий, но приделать к ассемблеру затычку, которая их транслирует не сложно. В чем там "великий прорыв"?

>Другое дело, что компилятро пишет менее эффективно, чем программист

Это не так. Компиляторы, особенно современные, часто пользуют для оптимизации экзотические трюки, типа использования команды процессора не по назначению. Рядовой программист не допетрит. Эффективность, по-крупному зависит от эффективности алгоритма. Быстрая сортировака и обычная - это же небо и земля. А на фортране процедура написана или на ассемблере практически без разницы.

>Т.е. программирование на асемблере необходимо только тогда, когда у вас ТЕХНИЧЕСКАЯ БАЗА слабая и вам надо ужаться по памяти и объему программы. Тогда надо посылать на фиг компилятор и самому делать его работу( писать на асмеблере).

Преимущество языков высокого уровня в переносимости с одной архитектуры на другую. А недостаток в трудностях привязки к технической базе. Будь то экзотическая система 60-х годов, нынешний "слабый" специализированный микроконтроллер или офигенно мощный, но специализированный графический процессор.
В 60-х проблемы переносимости не стояло. А проблема экзотического железа стояла и очень остро.

А проблема языков высокого уровня вовсе высосана из пальца. Это, в отличии от железа, не проблема вовсе.

>Т.е. писание на асемблере, в общем случае, это нужда. Жестокая, фиговая нужда.

Ерунду пишете. Какая у ученого "жесткая нужда"? Просто если написать процедуру кластерного анализа ДНК чипов или подобной информации для графической платы, чтобы работало в 50 раз быстрее обычного компа, можно изучать проблемы, которые рыньше заняли бы слишком много времени или денег. Жесткое любопытство заставляет, а никак не нужда :). А в универе мне было прикольно оптимизировать до предела поиск сайтов рестрикционных ферментов в ДНК. Битовыми операциями на 32-битных регистрах. Нужды никакой. Просто интересно, а как следствие - возможности.

>Но на это это все и погибло. "Интегральную" БЭСМ так и не создали, пытаясть родить этого уродца Эльбрус.

"все нажитое непосильным трудом - все же погибло!" (с)
Создали то, что должно быть интергральным - микропроцессоры.
-------------------
http://www.orossii.ru

От Iva
К Александр (21.08.2009 22:08:19)
Дата 21.08.2009 23:37:37

похоже это вы не пробовали

Привет

вы бы посмотрели что такое простой вызор SUBROUTINE или OUTPUT
там и не 50 строк за строку будет

>но даже не полюбопытствовал скомпилировать програмку в язык ассемблера, где исходный текст в виде комментариев, да посмотреть во сколько ассемблерных команд на самом деле компилируется строка языка высокого уровня. 3-4. Особенно если речь о фортране. Пожалуй единственное исключение - арифметические выражения и вызовы фунцкий, но приделать к ассемблеру затычку, которая их транслирует не сложно. В чем там "великий прорыв"?

а цикл? не видели что получается?

>Преимущество языков высокого уровня в переносимости с одной архитектуры на другую. А недостаток в трудностях привязки к технической базе. Будь то экзотическая система 60-х годов, нынешний "слабый" специализированный микроконтроллер или офигенно мощный, но специализированный графический процессор.
>В 60-х проблемы переносимости не стояло. А проблема экзотического железа стояла и очень остро.

тут согласен. Но это не снимает проблему производительности труда программиста. И трудности отладки - чем сложенее конструкция и чем больше в ней строк - тем сложнее.
Поэтому лучше, когда за тебя часть работы сделает язык высокого уровня и его компилятор.

>>Т.е. писание на асемблере, в общем случае, это нужда. Жестокая, фиговая нужда.
>
>Ерунду пишете. Какая у ученого "жесткая нужда"? Просто если написать процедуру кластерного анализа ДНК чипов или подобной информации для графической платы, чтобы работало в 50 раз быстрее обычного компа, можно изучать проблемы, которые рыньше заняли бы слишком много времени или денег. Жесткое любопытство заставляет, а никак не нужда :). А в универе мне было прикольно оптимизировать до предела поиск сайтов рестрикционных ферментов в ДНК. Битовыми операциями на 32-битных регистрах. Нужды никакой. Просто интересно, а как следствие - возможности.

Ограничение по ресурсам - по железу. Просто ваш опыт соверменный - мегабайты тут и там. А когда вам надо все запихнуть в 64-256К - тогда это уже не интерес - а насущная необходимость.

Нет хуже работы - пасти дураков. Бессмысленно храбрых - тем более.(Киплинг).

От Александр
К Iva (21.08.2009 23:37:37)
Дата 22.08.2009 11:07:27

Re: похоже это...

>Привет

>вы бы посмотрели что такое простой вызор SUBROUTINE или OUTPUT
>там и не 50 строк за строку будет

Берем простенькую прогу и транслируем ее в визуальном с++
#include "stdafx.h"
#include 

using std::cout;
using std::endl;


void soubroutine()
{
	int j=0;
	while (j<5)
		j++;
}
int _tmain(int argc, _TCHAR* argv[])
{
	cout<<"hello";
	soubroutine();
	return 0;
}



и глядим что во что транслируется вывод и вызов подпрограммы в строчках 16 и 17 соответственно.

; 16   : 	cout<<"hello";

	push	OFFSET ??_C@_05CJBACGMB@hello?$AA@
	mov	eax, DWORD PTR __imp_?cout@std@@3V?$basic_ostream@DU?$char_traits@D@std@@@1@A
	push	eax
	call	??$?6U?$char_traits@D@std@@@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@PBD@Z ; std::operator<< >
	add	esp, 8

; 17   : 	soubroutine();

	call	?soubroutine@@YAXXZ			; soubroutine

Вывод на консоль 5 строк
Вызов подпрограммы одна строка.


>>но даже не полюбопытствовал скомпилировать програмку в язык ассемблера, где исходный текст в виде комментариев, да посмотреть во сколько ассемблерных команд на самом деле компилируется строка языка высокого уровня. 3-4. Особенно если речь о фортране. Пожалуй единственное исключение - арифметические выражения и вызовы фунцкий, но приделать к ассемблеру затычку, которая их транслирует не сложно. В чем там "великий прорыв"?
>
>а цикл? не видели что получается?

Видели
; 11   : 	while (j<5)

	cmp	DWORD PTR _j$[ebp], 5
	jge	SHORT $LN3@soubroutin


Две строчки.
----------------------------
http://www.orossii.ru

От А.Б.
К Iva (21.08.2009 23:37:37)
Дата 22.08.2009 10:26:59

Re: Полагаю - пробовал.

>тут согласен. Но это не снимает проблему производительности труда программиста.

Только ее не надо исчислять в "строках\час" - будет как с СССР и госпланом. :)

Реальность такова, что толпы кодировщиков разучились чумать четко и связно. Именно из-за пристрастия только к языкам высокого уровня.

Кстати - вызов подпрограммы - спецом для "языков вусокого уровня" - реализуется именно 3-4 строками асма. Там есть такая фича как "ENTER/LEAVE" - команды процессора. Для RISC, конечно будет побольше, если тупо уподобляться заданной структуре передачи параметров. Если не тупо - то столько же.


От Alexandre Putt
К Александр (21.08.2009 22:08:19)
Дата 21.08.2009 23:15:01

Re: Сразу видно...

>но даже не полюбопытствовал скомпилировать програмку в язык ассемблера, где исходный текст в виде комментариев, да посмотреть во сколько ассемблерных команд на самом деле компилируется строка языка высокого уровня. 3-4.

Ну, конечно, куда авторам учебников по Фортрану до г-на Александра. Сами-то пробовали, или как обычно? Потрудитесь объяснить, как на ассемблере x86 будем тремя строчками с комплексными числами работать?

> В чем там "великий прорыв"?

В том, что можно написать sqrt(2.0) и не думать о тысяче вопросов аппаратной реализации этого.

> Эффективность, по-крупному зависит от эффективности алгоритма. Быстрая сортировака и обычная - это же небо и земля. А на фортране процедура написана или на ассемблере практически без разницы.

Разница есть, и местами существенная. Потому что язык бывает "заточен" под определённый круг задач и вместе с ним компилятор. Что касается ассемблера, то он может дать кратное увеличение скорости работы программы при грамотном использовании машинных команд.

>В 60-х проблемы переносимости не стояло. А проблема экзотического железа стояла и очень остро.

Умудряемся противоречить в двух предложениях. Переносимость для того и нужна, чтобы программа работала на любом железе.

От Александр
К Alexandre Putt (21.08.2009 23:15:01)
Дата 22.08.2009 10:00:06

Re: Сразу видно...

>>но даже не полюбопытствовал скомпилировать програмку в язык ассемблера, где исходный текст в виде комментариев, да посмотреть во сколько ассемблерных команд на самом деле компилируется строка языка высокого уровня. 3-4.
>
>Ну, конечно, куда авторам учебников по Фортрану до г-на Александра.

Что мешает дурачкам, в жизни не видившим ассемблера, писать учебник по фортрану?

>Сами-то пробовали, или как обычно?

Сами, как обычно, пробовали. И посмотреть как что транслируется и компилятор написать.

> Потрудитесь объяснить, как на ассемблере x86 будем тремя строчками с комплексными числами работать?

Легко :)))
push addr1
push addr2
call comlex_add

И именно в это странслируется соответствующий код с фортрана, если без оптимизации.

>> В чем там "великий прорыв"?
>
>В том, что можно написать sqrt(2.0) и не думать о тысяче вопросов аппаратной реализации этого.

Какие тысячи вопросов аппаратной реализации в двух строках

push 2.0
call sqrt

>> Эффективность, по-крупному зависит от эффективности алгоритма. Быстрая сортировака и обычная - это же небо и земля. А на фортране процедура написана или на ассемблере практически без разницы.
>
>Разница есть, и местами существенная. Потому что язык бывает "заточен" под определённый круг задач и вместе с ним компилятор.

Это касается сложных систем. На БЭСМ таких просто не было.

> Что касается ассемблера, то он может дать кратное увеличение скорости работы программы при грамотном использовании машинных команд.

При сортировке массива в миллион элементов даже интерпретатор бэйсика, работающий по алгоритму быстрой сортировки, обгонит ассемблерную реализацию обычной.

>>В 60-х проблемы переносимости не стояло. А проблема экзотического железа стояла и очень остро.
>
>Умудряемся противоречить в двух предложениях. Переносимость для того и нужна, чтобы программа работала на любом железе.

Программ не было. Стало быть, нечего и переносить.
А противоречия - они у вас в голове.
------------------------
http://www.orossii.ru

От Alexandre Putt
К Александр (22.08.2009 10:00:06)
Дата 23.08.2009 22:18:46

Ну прямо сразил

> call comlex_add

Откуда взялось complex_add? Дурочку включили?

На ассемблере
• нет стандартных библиотек
• нет управления памятью
• нет массивов
• нет поддержки вещественных чисел
• нет встроенных мат операций
• нет типов данных и структур

> Какие тысячи вопросов аппаратной реализации в двух строках

Вопросы организации операций с вещественными числами

> push 2.0
> call sqrt

Сразу видно, что на ассемблере Вы ни разу ничего не написали. Потому что на ассемблере нет поддержки вещественных чисел. Соответственно никакой push 2.0 не возможен

Я правильно понял, программа управления ядерным реактором у Вас тоже в одну строчку на ассемблере?

call RunReactor

?

Судя по всему, Вы даже не понимаете разницы между компилятором и языком программирования.

> Программ не было. Стало быть, нечего и переносить.

Ну вот Вы и охарактеризовали уровень развития ИТ в СССР: "Программ не было"

От Александр
К Alexandre Putt (23.08.2009 22:18:46)
Дата 24.08.2009 01:48:09

Re: Ну прямо...

>> call comlex_add
>
>Откуда взялось complex_add? Дурочку включили?

Оттуда же откуда на Фортране для SQRT(2.0), из библиотеки. Не вставлять же каждый раз весь алгоритм.

Если вас интересует как реализовано вычисление квадратных корней по методу Ньютона, то это и на фортране далеко не одна строчка

      function sqrt (x)
c june 1977 edition.   w. fullerton, c3, los alamos scientific lab.
      dimension sqrt2(3)
      external alog, r1mach, r9pak
      data sqrt2(1) / 0.7071067811 8654752e0 /
      data sqrt2(2) / 1.0 e0 /
      data sqrt2(3) / 1.4142135623 7309505 e0 /
c
      data niter / 0 /
c
      if (niter.eq.0) niter = 1.443*alog(-0.104*alog(0.1*r1mach(3)))+ 1.
c
      if (x.le.0.) go to 20
c
      call r9upak (x, y, n)
      ixpnt = n/2
      irem = n - 2*ixpnt + 2
c
c the approximation below has accuracy of 4.16 digits.
      sqrt = .261599e0 + y*(1.114292e0 + y*(-.516888e0 + y*.141067e0))
c
      do 10 iter=1,niter
        sqrt = sqrt + 0.5*(y - sqrt**2) / sqrt
 10   continue
c
      sqrt = r9pak (sqrt2(irem)*sqrt, ixpnt)
      return
c
 20   if (x.lt.0.) call seteru (21hsqrt    x is negative, 21, 1, 1)
      sqrt = 0.0
      return
c
      end

http://gams.nist.gov/serve.cgi/ModuleComponent/8035/Fullsource/NETLIB/sqrt.f

Впрочем, на х87ассемблере вычисление квадратного корня будет выглядеть так:
fld addr1
fsqrt
fst addr2


>На ассемблере
>• нет стандартных библиотек

Глупость.

>• нет управления памятью

Глупость

>• нет массивов

глупость

>• нет поддержки вещественных чисел

глупость. Посмотрите команды х87, или SSE

>• нет встроенных мат операций

глупость

>• нет типов данных и структур

глупость.

Как много и сразу :))

>> Какие тысячи вопросов аппаратной реализации в двух строках
>
>Вопросы организации операций с вещественными числами

Как то например?

>> push 2.0
>> call sqrt
>
>Сразу видно, что на ассемблере Вы ни разу ничего не написали. Потому что на ассемблере нет поддержки вещественных чисел. Соответственно никакой push 2.0 не возможен

Да у вас ничего невозможно, все только взрослые дяденьки делать могут.

      db    -0.2                    ; "Quarter precision" 
      dw    -0.5                    ; IEEE 754r/SSE5 half precision 
      dd    1.2                     ; an easy one 
      dd    1.222_222_222           ; underscores are permitted 
      dd    0x1p+2                  ; 1.0x2^2 = 4.0 
      dq    0x1p+32                 ; 1.0x2^32 = 4 294 967 296.0 
      dq    1.e10                   ; 10 000 000 000.0 
      dq    1.e+10                  ; synonymous with 1.e10 
      dq    1.e-10                  ; 0.000 000 000 1 
      dt    3.141592653589793238462 ; pi 
      do    1.e+4000                ; IEEE 754r quad precision
...
      mov    rax,__float64__(3.141592653589793238462)


http://www.nasm.us/doc/nasmdoc3.html#section-3.4.1

>Я правильно понял, программа управления ядерным реактором у Вас тоже в одну строчку на ассемблере?

"программа управления ядерным реактором" - это для дураков, вроде среднего американского старшекласника. ИБМ704 не могла этим заниматься в принципе. Реально речь идет о каких-то вычислениях.

>Судя по всему, Вы даже не понимаете разницы между компилятором и языком программирования.

Вам трудно судить о том что я понимаю и что нет.

>> Программ не было. Стало быть, нечего и переносить.
>
>Ну вот Вы и охарактеризовали уровень развития ИТ в СССР: "Программ не было"

И не только СССР
--------------------
http://www.orossii.ru