А мне кажется, что в первом варианте теряется связь между advanced optimization features и Intel® processors. Так что я мимо него проскочил, увидел, что "(advanced optimization features and multithreading capabilities and support for Intel® processors) and compatible processors" — бессмыслица и понял её как второй вариант.
Хорошо, мы не уверены в том, нет ли каких-то багов в поддержке SSE5 у AMD. Но для этого как раз и должна служить та задержка, о которой они говорят:
После того, как мы проверим функциональность с новыми процессорами Intel и AMD, мы обновляем компилятор. Это означает, что существует некоторое отставание с поддержкой новых процессоров в официальной версии компилятора.
Автор статьи как раз считает это вполне допустимым («звучит хорошо»).
И если они действительно обещали ещё три года назад включить поддержку для SSE3 у AMD в 10-й версии (то есть проверили и убедились, что багов нет), а до сих пор не включили даже поддержку SSE, то ситуация уже несколько другая.
Intel® Professional Edition Compilers include advanced optimization features, multithreading capabilities, and support for Intel® processors and compatible processors.
Выгода, полученная за 6 лет? Думаю, больше. Даже если указанное в статье «несправедливое рыночное преимущество ценой в миллиарды долларов» преувеличено, сомневаюсь, что потеря в репутации потянет хотя бы на миллион.
Тем более, что из ссылок видно, что информация несколько раз уже выходила, а вот Вы об этом слышали? Я услышал вчера в первый раз…
«adding in the real temps» означает не «изменил реальные температурные данные в сторону увеличения», а «заменил в конце серии реконструкции на реальные температурные данные, чтобы скрыть уменьшение реконструкций».
Алгебраические типы данных и всё, что удобно выражается именно через них, туда же. Как пример, тип для функций, которые часто оказываются константами и оптимизированы под это дело:
F#:
type 'a 'b optfun =
| Konst of 'b
| Fun of ('a -> 'b)
...
let x = Konst 0
C#:
abstract public class OptFun<A,B> {
public sealed class Konst {
B Value {get; private set;}
public Konst(B value) { Value = value; }
}
public sealed class Fun {
Func<A,B> Func {get; private set;}
public Konst(Func<A,B> func) { Func = func; }
}
// реализацию Equals, ==, !=, и GetHashCode добавьте сами
}
...
OptFun<int, int> x = new OptFun<int, int>.Konst(0)
// или в лучшем случае
var x = OptFun.Konst(0)
External DSL — это действительно «по большому счету разбор», а Internal DSL (о котором идёт речь) почему? (Впрочем, синтаксис F#, по-моему, для IDSL подходит всё-таки существенно хуже, чем те же Ruby и Scala.)
Visual Prolog — нестандартный Prolog с очень большими отличиями (т.е. знания по нему во многом на остальные Прологи не переносятся). Я лично использую SWI-Prolog + SWI-Prolog-Editor.
Я, впрочем, тоже не лингвист :)
Автор статьи как раз считает это вполне допустимым («звучит хорошо»).
И если они действительно обещали ещё три года назад включить поддержку для SSE3 у AMD в 10-й версии (то есть проверили и убедились, что багов нет), а до сих пор не включили даже поддержку SSE, то ситуация уже несколько другая.
Тем более, что из ссылок видно, что информация несколько раз уже выходила, а вот Вы об этом слышали? Я услышал вчера в первый раз…
F#:
Ближайший аналог, который мне удалось получить в C#:
FList<Tuple<A,B>> Zip<A,B>(FList<A> la, FList<B> lb) { return la.Match( () => FList<Tuple<A,B>>.Empty, (ha, ta) => lb.Match( () => FList<Tuple<A,B>>.Empty, (hb, tb) => Tuple.New(ha, hb).Cons(Zip(la, lb)))); }Я лично предпочту первый вариант.
Алгебраические типы данных и всё, что удобно выражается именно через них, туда же. Как пример, тип для функций, которые часто оказываются константами и оптимизированы под это дело:
F#:
type 'a 'b optfun = | Konst of 'b | Fun of ('a -> 'b) ... let x = Konst 0C#:
abstract public class OptFun<A,B> { public sealed class Konst { B Value {get; private set;} public Konst(B value) { Value = value; } } public sealed class Fun { Func<A,B> Func {get; private set;} public Konst(Func<A,B> func) { Func = func; } } // реализацию Equals, ==, !=, и GetHashCode добавьте сами } ... OptFun<int, int> x = new OptFun<int, int>.Konst(0) // или в лучшем случае var x = OptFun.Konst(0)Lisp — нужен Lisp вообще, т.е. какой-то язык этого семейства? Тогда для Common Lisp есть LispBox и Lisp in a Box, а для Scheme PLT Scheme с отличной средой DrScheme